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