Re: wal_buffers = -1 and SIGHUP

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: wal_buffers = -1 and SIGHUP
Дата
Msg-id 2003.1301784617@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: wal_buffers = -1 and SIGHUP  (Robert Haas <robertmhaas@gmail.com>)
Ответы GUC assign hooks (was Re: wal_buffers = -1 and SIGHUP)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Mar 31, 2011 at 8:38 AM, Bernd Helmle <mailings@oopsware.de> wrote:
>> This might be nitpicking (or i'm currently missing something), but i
>> recognized that setting wal_buffers = -1 always triggers the following on
>> reload, even if nothing to wal_buffers had changed:
>> 
>> $ pg_ctl reload
>> LOG: �received SIGHUP, reloading configuration files
>> LOG: �parameter "wal_buffers" cannot be changed without restarting the
>> server
>> 
>> This only happens when you have wal_buffers set to -1.

> This is a bug.  The root cause is that, on startup, we do this:

>         if (xbuffers != XLOGbuffers)
>         {
>                 snprintf(buf, sizeof(buf), "%d", xbuffers);
>                 SetConfigOption("wal_buffers", buf, PGC_POSTMASTER,
> PGC_S_OVERRIDE);
>         }

> I had intended to commit Greg's patch with a show hook and an assign
> hook and the calculated value stored separately from the GUC variable,
> which I believe would avoid this is a problem, but Tom thought this
> way was better.  Unfortunately, my knowledge of the GUC machinery is
> insufficient to think of a way to avoid it, other than the one Tom
> already rejected.

Mph ... I think this shows the error of my thinking :-(.  We at least
need an assign hook here.  Will fix, since it was my oversight to begin
with.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: psql 9.1 alpha5: connection pointer is NULL
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Process local hint bit cache