Re: Parameter name standby_mode

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Joachim Wieland <joe(at)mcknight(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parameter name standby_mode
Date: 2010-03-31 13:44:11
Message-ID: m2l603c8f071003310644n53ef192cjc877a955a8151b5a@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 31, 2010 at 1:47 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Wed, Mar 31, 2010 at 12:21 PM, Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2010-03-31 13:45:59 Re: sorry, too many standbys already vs. MaxWalSenders vs. max_wal_senders
Previous Message Robert Haas 2010-03-31 13:34:02 Re: sorry, too many standbys already vs. MaxWalSenders vs. max_wal_senders