agora inbox for [email protected]
help / color / mirror / Atom feedFrom: Heikki Linnakangas <[email protected]>
To: Simon Riggs <[email protected]>
Cc: Fujii Masao <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Guillaume Smet <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Kevin Grittner <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: New trigger option of pg_standby
Date: Thu, 14 May 2009 23:31:18 +0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
I've finally committed Simon's recovery_end_command patch, as well as
the changes to pg_standby. There's now smart and fast failover modes,
chosen by the content of the trigger file, smart mode is the default. A
"fast" trigger file is truncated, turning it into a "smart" trigger for
subsequent pg_standby invocations. I believe this is now safe in all the
combinations discussed, in both fast and smart mode, with or without
extra WAL files copied to pg_xlog, and also if the last archived WAL
file is incomplete.
You now need to set up recovery_end_command to clean up the trigger
file; pg_standby no longer does that automatically.
Simon Riggs wrote:
> On Fri, 2009-05-15 at 03:49 +0900, Fujii Masao wrote:
>> Hi,
>>
>> On Fri, May 15, 2009 at 12:36 AM, Simon Riggs <[email protected]> wrote:
>>> On Wed, 2009-05-13 at 21:43 +0100, Simon Riggs wrote:
>>>> On Wed, 2009-05-13 at 21:26 +0300, Heikki Linnakangas wrote:
>>>>
>>>>> This whole thing can be considered to be a new feature.
>>>> recovery.conf will contain a new optional parameter:
>>>>
>>>> recovery_end_command (string)
>>> Implemented.
>>> + ereport(signaled ? FATAL : WARNING,
>>> + (errmsg("recovery_end_command \"%s\": return code %d",
>>> + xlogRecoveryEndCmd, rc)));
>> In fast failover case, pg_standby has to delete the trigger file immediately
>> if it's found. Otherwise, recovery may go wrong as I already described.
>> http://archives.postgresql.org/pgsql-hackers/2009-04/msg01139.php
>>
>> So, in fast mode, recovery_end_command would always fail to delete the
>> trigger file, and cause warning. This is odd behavior, I think. We should
>> change WARNING to DEBUG2 like RestoreArchivedFile() in the above code?
>
> Using rm -f would avoid the WARNING.
>
> I'd rather keep it at WARNING, since not sure what command I'll be
> running and what a non-zero rc means.
>
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
view thread (150+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: New trigger option of pg_standby
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox