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

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.

You're welcome to complete the implementation using this patch, or
I'll do that when I get back from leave.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services