Re: auto-sizing wal_buffers - Mailing list pgsql-hackers

From Tom Lane
Subject Re: auto-sizing wal_buffers
Date
Msg-id 202.1295748502@sss.pgh.pa.us
Whole thread Raw
In response to Re: auto-sizing wal_buffers  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: auto-sizing wal_buffers  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> This is certainly shorter than I wrote, which is good, but it strikes
> me that the fundamental problem here is that the API for an assign
> hook is fundamentally different for strings than it is for other data
> types.

I agree that that's annoying, but given that strings are pass-by-ref
while the other GUC variable types are pass-by-value, it's not really
very easy to make them alike.

In any case, it's not too relevant to this patch, because an assign hook
cannot solve this problem.  As someone (I think you) pointed out
upthread, an assign hook would only be useful if we were sure
wal_buffers would in fact be assigned to by the config file, and that
that would happen after shared_buffers acquired its final value.  Since
we can't assume either thing, the right way to approach it is to have an
internal action that assigns a fresh value to wal_buffers after all the
configuration processing is complete.  Greg had the right design but
didn't know how to change a GUC setting properly.  There are a bunch of
other hacks^Wfeatures that work similarly --- look around for
SetConfigOption calls.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg_dump --split patch
Next
From: Robert Haas
Date:
Subject: Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements.