Re: New trigger option of pg_standby - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: New trigger option of pg_standby
Date
Msg-id 3f0b79eb0905130127u3a3275b1w79f4d8cb729ded36@mail.gmail.com
Whole thread Raw
In response to Re: New trigger option of pg_standby  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: New trigger option of pg_standby  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
Hi,

On Tue, May 12, 2009 at 8:15 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> Fujii Masao wrote:
>>
>> On Thu, Apr 23, 2009 at 4:49 PM, Heikki Linnakangas
>> <heikki.linnakangas@enterprisedb.com> wrote:
>>>
>>> This is getting complicated, though. I guess it would be enough to
>>> document
>>> that you mustn't copy any extra files into pg_xlog if you use a fast
>>> trigger.
>>
>> Agreed. I added this note into document.
>>
>> Attached is the updated patch. I also fixed my bug which
>> pg_standby returns 0 even if the requested file fails to be
>> restored in smart mode.
>>
>> This patch is ready to commit, I think. Please review this.
>
> Looking at this again..
>
> Deleting the trigger file when a history file is requested:
>
>>                /*
>>                 * Get rid of the trigger file at the end of archive
>> recovery.
>>                 * Otherwise, it would unexpectedly cause the subsequent
>> warm-standby to
>>                 * end.
>>                 *
>>                 * Here is the right place to remove the trigger file since
>> a timeline
>>                 * history file is requested only at the beginning and end
>> of archive
>>                 * recovery.
>>                 */
>
> changes the behavior in a subtle way: if you create trigger file before
> starting recovery, it will be deleted when the recovery is started and no
> failover is done. Currently, it will end the recovery immediately.
>
> That makes me uncomfortable to back-patch this. That change in behavior
> might be hard to work-around: the process that creates the trigger file
> would have to make sure that the server has started recovery before creating
> the file.
>
> Here's another idea: Let's modify xlog.c so that when the server asks for
> WAL file X, and restore_command returns "not found", the server will not ask
> for any WAL files >= X again (in that recovery session). Presumably if X
> doesn't exist, no later files will exist either. That would be pretty simple
> change, and it would allow us to go with the simpler implementation in
> pg_standby and just remove the trigger file immediately when it returns "not
> found" (instead of removing it when history file is requested). That would
> make it safe to copy extra WAL files into pg_xlog, even in fast failover
> mode.
>
> Does anyone see a hole in that idea?

Probably yes. The trigger file would remain after failover if the
restored WAL file has the invalid record which means the end
of WAL. In this case, "not found" is not returned.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


pgsql-hackers by date:

Previous
From: Asko Oja
Date:
Subject: Re: display previous query string of idle-in-transaction
Next
From: Heikki Linnakangas
Date:
Subject: Re: New trigger option of pg_standby