Re: auto-sizing wal_buffers

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

In response to

Responses

Browse pgsql-hackers by date

  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