Re: wal_buffers = -1 and SIGHUP

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: wal_buffers = -1 and SIGHUP
Дата
Msg-id AANLkTin4o+eSgQsP=0i6EM=Evu3oX=ewHp8Bwod1UaWZ@mail.gmail.com
обсуждение исходный текст
Ответ на wal_buffers = -1 and SIGHUP  (Bernd Helmle <mailings@oopsware.de>)
Ответы Re: wal_buffers = -1 and SIGHUP
Список pgsql-hackers
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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Windows build issues
Следующее
От: Dave Page
Дата:
Сообщение: Re: Windows build issues