From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: auto-sizing wal_buffers |
Date: | 2011-01-23 02:08:22 |
Message-ID: | 202.1295748502@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-01-23 02:11:27 | Re: [PATCH] Return command tag 'REPLACE X' for CREATE OR REPLACE statements. |
Previous Message | Robert Haas | 2011-01-23 02:04:33 | Re: pg_dump --split patch |