Skip site navigation (1) Skip section navigation (2)

Re: Parameter name standby_mode

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(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 21:26:05
Message-ID: m2n603c8f071003311426w82ef64b7se410eef0917efa10@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Mar 31, 2010 at 5:23 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> Robert Haas wrote:
>> Is it reasonable to think that we can find a way to make it not print
>> the duplicate messages over and over again?
>>
>> LOG:  record with zero length at 0/3006B28
>>
>> Maybe only print that if the location has advanced since the last such message?
>
> Yeah, seems reasonable.
>
>> Should we make it shut down if it can't immediately read enough WAL to
>> get to a consistent state, or just figure it's the user's job to fix
>> it?
>
> I'd say no. In testing, I have done this many times:
>
> pg_start_backup()
> copy data directory to server
> create recovery.conf
> Start standby server.
> pg_stop_backup()
>
> The standby doesn't reach consistency before it sees the end-of-backup
> record written by pg_stop_backup(), but it does replay up to the last
> WAL segment, and connect to the master.
>
> Not sure if that's useful in real life, but there could be situations
> where restore_command isn't totally reliable, for example, and it's good
> to keep trying.

I was only thinking of doing it in the case where there's no
primary_conninfo or restore_command.

...Robert

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2010-03-31 22:38:35
Subject: Re: psql: edit function, show function commands patch
Previous:From: Heikki LinnakangasDate: 2010-03-31 21:23:56
Subject: Re: Parameter name standby_mode

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group