Re: [PATCH] Cleanup of GUC units code - Mailing list pgsql-hackers

From Greg Smith
Subject Re: [PATCH] Cleanup of GUC units code
Date
Msg-id Pine.GSO.4.64.0809091834350.16003@westnet.com
Whole thread Raw
In response to Re: [PATCH] Cleanup of GUC units code  ("Robert Haas" <robertmhaas@gmail.com>)
Responses Re: [PATCH] Cleanup of GUC units code  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [PATCH] Cleanup of GUC units code  ("Robert Haas" <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, 9 Sep 2008, Robert Haas wrote:

> A good start might be to always OUTPUT memory parameters using the
> same base unit.

SHOW gives output that matches what you input.  If you want to see things 
with consistant units, look at pg_settings:

# select name,unit,setting,current_setting(name) from pg_settings where 
name='shared_buffers' or name='temp_buffers';
      name      | unit | setting | current_setting
----------------+------+---------+----------------- shared_buffers | 8kB  | 131072  | 1GB temp_buffers   | 8kB  | 1024
 | 1024
 

> Beyond that, how about moving in the direction of deprecating
> unit-less settings altogether?  In other words, if you want 1024
> shared buffers, you should be saying 8192kB or 8MB rather than 1024.
> We could issue a WARNING for 8.4 and eventually move to rejecting that
> syntax altogether.  That gets everything into the same base unit
> without ever change the semantics of any particular value.

Deprecating setting the value directly in its base unit, so that all the 
memory parameters are specified as a number of bytes, would sidestep a lot 
of the issues people complain about.  What I would like to see (but don't 
have nearly enough time to argue in support of considering the resistance 
to change here) is that this syntax:

shared_buffers=1024

Would assume the user meant 1024 *bytes*, with the server silently 
rounding that up to the nearest 8k block.  Then the whole issue of "do 
they mean bits or bytes?" goes away, because no one would ever have to 
include the "B".  That paves the way for making it easy to support 
case-insensitive values without pedantic confusion.  As I see it these 
should all give you the same thing:

shared_buffers=16777216
shared_buffers=16384k
shared_buffers=16384K
shared_buffers=16M
shared_buffers=16m

Because that's what would make life easiest for those configuring the 
software.

Since this suggestion will inevitably lead to cries of befowled backward 
compatibility, what I've been doing instead of participating in this 
thread is working on a tool that will make it easy to convert old 
postgresql.conf files to support a new version.  Then the tool can convert 
all the places someone uses the old syntax into the new.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD


pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: [PATCH] Cleanup of GUC units code
Next
From: David Fetter
Date:
Subject: Re: Keeping creation time of objects