Re: Parameter name standby_mode - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Parameter name standby_mode
Date
Msg-id m2g3f0b79eb1003302247yc322dfa9pdfdc454b83e6120f@mail.gmail.com
Whole thread Raw
In response to Re: Parameter name standby_mode  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Parameter name standby_mode
List pgsql-hackers
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.

> 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.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: sorry, too many standbys already vs. MaxWalSenders vs. max_wal_senders
Next
From: Dmitry Fefelov
Date:
Subject: Feature request - function-based deferrable uniques.