Re: Prevent restored WAL files from being archived again Re: Unnecessary WAL archiving after failover

On Thu, Aug 9, 2012 at 11:24 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 9 August 2012 00:08, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
>> Will look at the refactored version tomorrow.
>
>
> Rather than implement the minimal patch onto HEAD, I've written a
> refactored patch. [attached]
> This fixes the bugs discussed here, though allows for multiple archive
> statuses, rather than just two, as well as removing similar code.
>
> We've talked about allowing file based replication to cascade, i.e.
> having the archiver run on standby and to push files onwards from the
> standby.
>
> The way I'd like to do this is
>
> If archiving active
> * Allow archiver to run on standby
> * When xlog file written on standby it sets archive_status to ".standby"
> * When archiver runs it will execute archive_command when it sees a
> status of ".ready" or it will execute standby_archive_command when it
> sees a status of ".standby". In both cases it will set a status of
> ".done" when complete. It doesn't need to know whether promotion has
> happened, or even when it happened, because the status of the xlog
> files is clearly marked.
>
> We can't use ".ready" to mean two things because then we'd be confused
> how to handle files generated during standby but archived after
> promotion has taken place. ".done" always means you can clean up the
> xlog files now, in all cases.

Sounds good to me.

Regards,

--
Fujii Masao