Re: [PATCH] Cleanup of GUC units code

>> A good start might be to always OUTPUT memory parameters using the
>> same base unit.
> SHOW gives output that matches what you input.

Not for me it doesn't.

portal=# show temp_buffers;
temp_buffers
--------------
1024
(1 row)

portal=# set temp_buffers = '16MB';
SET
portal=# show temp_buffers;
temp_buffers
--------------
2048
(1 row)

> 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

Silly me, perhaps, but in the absence of a unit, I would assume that a
number in this context refers to a number of BUFFERS. I'd be willing
to bet money that if you showed this line to a bunch of people who
knew nothing about postgresql but were reasonably computer-savvy,
you'd get a lot more people who thought that was a number of buffers
than who thought it was a number of bytes.

Compounding the problem, of course, is the fact, that right now,
that's exactly what it does mean. While it's probably acceptable to
change the semantics of postgresql.conf in such a way that this syntax
is no longer accepted, or generates a warning, it's almost certainly a
bad idea to change it to silently mean something that is four orders
of magnitude different what it currently means.

> 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".

I don't believe this issue exists in the first place, because anyone
who would specify the size of their shared buffer pool in bits should
have their head examined. But if, hypothetically, someone were
confused, I can't imagine that taking away the "B" is somehow going to
be more clear.

...Robert