Re: New trigger option of pg_standby

Fujii Masao wrote:
> On Mon, Apr 20, 2009 at 6:06 PM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> What's wrong with just this: (ignoring the missing fast option)
>>
>> --- a/contrib/pg_standby/pg_standby.c
>> +++ b/contrib/pg_standby/pg_standby.c
>> @@ -552,8 +552,6 @@ main(int argc, char **argv)
>> break;
>> case 't': /* Trigger file */
>> triggerPath = optarg;
>> - if (CheckForExternalTrigger())
>> - exit(1); /* Normal exit, with non-zero */
>> break;
>> case 'w': /* Max wait time */
>> maxwaittime = atoi(optarg);
>>
>> ie. only check and delete the trigger file once the server requests a file
>> that doesn't exist.
>
> Thanks for the suggestion! I have three comments.
>
> 1)
> Though some users want to save the fast failover mode, this
> solution doesn't provide it. You think that that mode is
> unnecessary?

No I just left it out to keep it simple. The patch was only meant to
make the point, I didn't intend it to be applied as is.

> 2)
> This solution would go wrong when there are the WAL files in
> pg_xlog; If pg_xlog of the primary server can be read at failover
> (it's not node failure but process failure case), the WAL files in
> it may be copied to pg_xlog of the standby server in order to
> prevent the transaction loss.
>
> On the other hand, we can copy such files to the archival storage
> instead of pg_xlog. In this case, your simple solution goes well,
> but recovery would unexpectedly end without the trigger file
> because those WAL files have the invalid record which means
> the end of WAL.
>
> I'd like to control when the standby will come up as a normal
> server. So, I think that pg_standby should cope with also the
> above situation which I described. What is your opinion?

Hmm, the user manual instructs to copy any unarchived files directly
into pg_xlog, but I guess you could copy them to the archive instead.

At the end of archive recovery, the server always probes for the
timeline by requesting history files until it fails to find one. That
probing should remove the trigger file if it hasn't been removed by
then. It's a bit coincidental to rely on that, but at least it's simple.
The assumption we're making is that the server won't exit recovery
before asking restore_command for a file that doesn't exist.

> 3)
> This solution has a race condition; some transactions would
> be lost if WAL file is shipped from the primary server and the
> trigger file is created, while pg_standby is sleeping, because
> pg_standby checks previously whether a trigger file exists.

Yeah, it should sleep only after checking for the trigger file. That
doesn't completely eliminate the race condition though: I think it
should check again that the WAL file doesn't exist after reading the
trigger file but before deleting it.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com