Re: Parameter name standby_mode
От | Robert Haas |
---|---|
Тема | Re: Parameter name standby_mode |
Дата | |
Msg-id | m2l603c8f071003310644n53ef192cjc877a955a8151b5a@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parameter name standby_mode (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: Parameter name standby_mode
|
Список | pgsql-hackers |
On Wed, Mar 31, 2010 at 1:47 AM, Fujii Masao <masao.fujii@gmail.com> wrote: > On Wed, Mar 31, 2010 at 12:21 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> I just tested this and it seems to just sit there doing this over and >> over again: >> >> LOG: record with zero length at 0/3006B28 >> >> I'm not sure that we should forbid this configuration, but the current >> behavior doesn't seem right either. ISTM that, in the absence of a >> way to get any more WAL, it would be reasonable for the standby server >> to just start up and sit there in recovery mode but without actually >> advancing recovery, but the repeated log messages are pretty annoying. > > I'm concerned about that the configuration might prevent the standby > from accepting connection from a client because it cannot get the WAL > for making the database consistent. So that configuration seems to be > reasonable only when starting the standby from the already-consistent > database or with enough WAL files in pg_xlog. But it seems to me that > the standby often starts from the inconsistent database without enough > WAL in pg_xlog. Agreed. I think if the server starts up in standby mode and it is an inconsistent state with no source of WAL, then the startup process should exit with a suitable error message, which AIUI will result in the whole server shutting down. However if there is no source of WAL but the server is in a consistent state, then I think we should allow it to start up as a read-only standby. Now, an interesting question is - if the server is in this state, and somebody manually drops more WAL into pg_xlog, what happens? And what happens in the similar case where primary_conninfo is set but we can't connect to the master at the moment, and someone drops a pile of WAL on us? >> A related question is... do we ever reload recovery.conf? I tried >> adding the setting to recovery.conf and doing pg_ctl reload, and it >> says that it's "reloading configuration files", but doesn't pick up >> the new setting. :-( > > recovery.conf cannot be reloaded while the server is running. This > restriction should be removed in the future release, I think. Yes. If we don't already have a TODO for that, we should definitely add one. I found myself annoyed by this several times last night. I kept having to restart the master, too, first to fix archive_mode and then to fix max_wal_senders. It's far too late to start tinkering with this stuff now but I am pretty confident there will be a huge sigh of collective relief out there if we can relax some of these restrictions for 9.1. Nobody likes having to shut down the server, even if it's just for a few seconds. ...Robert
В списке pgsql-hackers по дате отправления: