Patch for units in postgresql.conf

Started by Peter Eisentrautabout 20 years ago4 messagespatches
Jump to latest
#1Peter Eisentraut
peter_e@gmx.net

Here is a preliminary patch for units in postgresql.conf (and SET and so on,
of course). It currently supports memory units only. Time units would be
similar. Let me know if you have comments.

(FWIW, work_mem is a good parameter to play with for trying this out.)

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Attachments:

guc-units.patchtext/x-diff; charset=us-ascii; name=guc-units.patchDownload+80-10
#2Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Peter Eisentraut (#1)
Re: Patch for units in postgresql.conf

Peter Eisentraut wrote:

+	if ((flags & (GUC_UNIT_KB|GUC_UNIT_BLOCKS)) && endptr != value)
+	{
+		bool used = false;
+
+		while (*endptr == ' ')
+			endptr++;
+
+		if (strcmp(endptr, "kB") == 0)
+		{
+			val *= KILOBYTE;
+			used = true;
+			endptr += 2;
+		}

Does this mean that one must match the "kB" exactly, with the specified
upper and lower case?

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

#3Peter Eisentraut
peter_e@gmx.net
In reply to: Alvaro Herrera (#2)
Re: Patch for units in postgresql.conf

Am Dienstag, 25. Juli 2006 15:12 schrieb Alvaro Herrera:

Does this mean that one must match the "kB" exactly, with the specified
upper and lower case?

I think it's better to require exact spelling of the units, or else it'll
quickly get inconsistent and error-prone. (Say, if you want to allow "KB",
why not "mB"? And "kb" is clearly a kilobit, so we don't want to allow that
in any case.)

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

#4Zdenek Kotala
Zdenek.Kotala@Sun.COM
In reply to: Peter Eisentraut (#1)
Re: Patch for units in postgresql.conf

Peter Eisentraut wrote:

Here is a preliminary patch for units in postgresql.conf (and SET and so on,
of course). It currently supports memory units only. Time units would be
similar. Let me know if you have comments.

The concept is good. However, parse should generate overflow. You
multiply first time and convert value to bytes and after you divide it.
By my opinion, better solution is compute number and
direction(multiply/divide) of shift bits and do it in one step.

There is small concept:

------------
int shift_tab[][] = { { 0 , -10, -20, -30 },
{ 10, 0 , -10, -20 },
{ 20, 10, 0 , -10 },
{ 30, 20, 10, 0 },
{ shift for block } };

if (strcmp(endptr, "kB") == 0)
{
shift = shift_tab[1][ flags & ..... ];
used = true;
endptr += 2;
}

if( shift < 0 )
val >> = shift;
else
{
int mask = ~0;
mask << = shift;
if( val & mask == 0 )
val << = shift;
else
....!!! Overflow
}

--------------------

I am not sure but I expect that values are stored in native format
(native unit). I think, there is not reason to divide/multiply it?

@@ -5082,8 +5124,34 @@
val = (*conf->show_hook) ();
else
{
-					snprintf(buffer, sizeof(buffer), "%d",
-							 *conf->variable);
+					char unit[3];
+					int result = *conf->variable;
+
+					if (record->flags & (GUC_UNIT_KB|GUC_UNIT_BLOCKS))
+					{
+						if (record->flags & GUC_UNIT_BLOCKS)
+							result *= BLCKSZ/1024;
+

Zdenek