Re: [PATCH] Cleanup of GUC units code

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <stark(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Marko Kreen <markokr(at)gmail(dot)com>, Asko Oja <ascoja(at)gmail(dot)com>
Subject: Re: [PATCH] Cleanup of GUC units code
Date: 2008-09-09 22:55:38
Message-ID: Pine.GSO.4.64.0809091834350.16003@westnet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2008-09-10 00:06:03 Re: Keeping creation time of objects
Previous Message Hannu Krosing 2008-09-09 20:47:28 Re: [PATCH] Cleanup of GUC units code