Re: Prevent restored WAL files from being archived again Re: Unnecessary WAL archiving after failover - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Prevent restored WAL files from being archived again Re: Unnecessary WAL archiving after failover
Date
Msg-id CA+U5nMLxKseoEG5zVFY_qVrUY7quq9_Fv+5atTiR-B2uxTdMqg@mail.gmail.com
Whole thread Raw
In response to Re: Prevent restored WAL files from being archived again Re: Unnecessary WAL archiving after failover  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Prevent restored WAL files from being archived again Re: Unnecessary WAL archiving after failover
List pgsql-hackers
On 9 August 2012 00:08, Simon Riggs <simon@2ndquadrant.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

Attachment

pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Wiki link for max_connections? (Fwd: Re: [ADMIN] PostgreSQL oom_adj postmaster process to -17)
Next
From: Tom Lane
Date:
Subject: Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap