Re: Bogus WAL segments archived after promotion - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Bogus WAL segments archived after promotion
Date
Msg-id 549489FA.4010304@vmware.com
Whole thread Raw
In response to Bogus WAL segments archived after promotion  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: Bogus WAL segments archived after promotion  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On 12/19/2014 02:55 PM, Heikki Linnakangas wrote:
> I'm thinking that we should add a step to promotion, where we scan
> pg_xlog for any segments higher than the timeline switch point, and
> remove them, or mark them with .done so that they are not archived.
> There might be some real WAL that was streamed from the primary, but not
> yet applied, but such WAL is of no interest to that server anyway, after
> it's been promoted. It's a bit disconcerting to zap WAL that's valid,
> even if doesn't belong to the current server's timeline history, because
> as a general rule it's good to avoid destroying evidence that might be
> useful in debugging. There isn't much difference between removing them
> immediately and marking them as .done, though, because they will
> eventually be removed/recycled anyway if they're marked as .done.

This is what I came up with. This patch removes the suspect segments at
timeline switch. The alternative of creating .done files for them would
preserve more evidence for debugging, but OTOH it would also be very
confusing to have valid-looking WAL segments in pg_xlog, with .done
files, that in fact contain garbage.

The patch is a bit longer than it otherwise would be, because I moved
the code to remove a single file from RemoveOldXlogFiles() to a new
function. I think that makes it more readable in any case, simply
because it was so deeply indented in RemoveOldXlogFiles.

Thoughts?

- Heikki

Attachment

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Role Attribute Bitmask Catalog Representation
Next
From: Heikki Linnakangas
Date:
Subject: Re: Streaming replication and WAL archive interactions