Обсуждение: BUG #5206: wal_sync_method in stock postgresql.conf may be wrong

The following bug has been logged online:

Bug reference:      5206
Logged by:          Alvaro Herrera
Email address:      alvherre@postgresql.org
PostgreSQL version: any
Operating system:   any
Description:        wal_sync_method in stock postgresql.conf may be wrong
Details:

Jaime Casanova just made me note that though most commented variables in
postgresql.conf list the value that they have because of being the default,
this is not the case with wal_sync_method -- it instead says "fsync" and
then explains in a comment that the real value is something else.

Now I understand why this is (it's because of the fact that the default
value is platform-dependent), but it still is a bit unfortunate and it would
be better to avoid it.

I have two suggestions to fix this:

1. avoid displaying any value at all as if it were the true default (this
would perhaps make the line invalid were the user to uncomment it)

2. change initdb so that it modifies that line too (along with
shared_buffers etc) to put the actual default value in there, but without
uncommenting it.

I also have one non-suggestion:

3. do nothing

Thoughts?

On Fri, Nov 20, 2009 at 6:56 PM, Alvaro Herrera <alvherre@postgresql.org> w=
rote:
>
> The following bug has been logged online:
>
> Bug reference: =A0 =A0 =A05206
> Logged by: =A0 =A0 =A0 =A0 =A0Alvaro Herrera
> Email address: =A0 =A0 =A0alvherre@postgresql.org
> PostgreSQL version: any
> Operating system: =A0 any
> Description: =A0 =A0 =A0 =A0wal_sync_method in stock postgresql.conf may =
be wrong
> Details:
>
> Jaime Casanova just made me note that though most commented variables in
> postgresql.conf list the value that they have because of being the defaul=
t,
> this is not the case with wal_sync_method -- it instead says "fsync" and
> then explains in a comment that the real value is something else.
>
> Now I understand why this is (it's because of the fact that the default
> value is platform-dependent), but it still is a bit unfortunate and it wo=
uld
> be better to avoid it.
>
> I have two suggestions to fix this:
>
> 1. avoid displaying any value at all as if it were the true default (this
> would perhaps make the line invalid were the user to uncomment it)
>
> 2. change initdb so that it modifies that line too (along with
> shared_buffers etc) to put the actual default value in there, but without
> uncommenting it.
>
> I also have one non-suggestion:
>
> 3. do nothing
>
> Thoughts?

I like #3 or #1 better than #2.   Putting logic into initdb to edit
the comments in the file doesn't really seem like a worthwhile use of
time.  (I still think we should get rid of the commented-out settings
altogether, but that's another argument...)

...Robert

Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Nov 20, 2009 at 6:56 PM, Alvaro Herrera <alvherre@postgresql.org> wrote:
>> I have two suggestions to fix this:
>>
>> 1. avoid displaying any value at all as if it were the true default (this
>> would perhaps make the line invalid were the user to uncomment it)
>>
>> 2. change initdb so that it modifies that line too (along with
>> shared_buffers etc) to put the actual default value in there, but without
>> uncommenting it.
>>
>> I also have one non-suggestion:
>>
>> 3. do nothing

> I like #3 or #1 better than #2.   Putting logic into initdb to edit
> the comments in the file doesn't really seem like a worthwhile use of
> time.

I agree, it seems like more work than the problem is worth.  We could
change the entry to something like

#wal_sync_method = (platform-dependent)    # the default is ...

> (I still think we should get rid of the commented-out settings
> altogether, but that's another argument...)

That's another reason not to expend work here --- it still seems
fairly likely that that might happen.

            regards, tom lane