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)
|
Список | 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 по дате отправления: