Re: Add timeline to partial WAL segments - Mailing list pgsql-hackers

From David Steele
Subject Re: Add timeline to partial WAL segments
Date
Msg-id c615e1a4-04d8-c7d0-c252-fb3e6b874b28@pgmasters.net
Whole thread Raw
In response to Re: Add timeline to partial WAL segments  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Add timeline to partial WAL segments
List pgsql-hackers
On 12/15/18 1:56 AM, Michael Paquier wrote:
> On Fri, Dec 14, 2018 at 06:05:18PM -0500, David Steele wrote:
>> On 12/14/18 3:26 PM, Robert Haas wrote:
>>> The new TLI is the only thing that is guaranteed to be unique with
>>> each new promotion, and I would guess that it is therefore the right
>>> thing to use to disambiguate them.
>>
>> This is the conclusion we came to after a few months of diagnosing and
>> working on this problem.
> 
> Hm.  Okay.  From that point of view I think that we should also make
> pg_receivewal able to generate the same kind of segment format when it
> detects a timeline switch for the last partial segment of the previous
> timeline.  Switching to a new timeline makes the streaming finish, so we
> could use that to close properly the WAL segment with the new name.  At
> the same time it would be nice to have a macro able to generate a
> partial segment name and also check after it.

Or perhaps just always add the timeline to the .partial?  That way it 
doesn't need to be renamed later.  Also, there would be a consistent 
name, rather than sometimes .partial, sometimes .<timelime>.partial.

>> The question in my mind: is it safe to back-patch?
> 
> That's unfortunately a visibility change, meaning that any existing
> backup solution able to handle .partial segments would get broken in a
> minor release.  From that point of view this should go only on HEAD.

That means every archive command needs to deal with this issue on its 
own.  It's definitely not a trivial thing to do.

It's obviously strong to call this a bug, but there's very clearly an 
issue here.  I wonder if there is anything else we can do that would work?

> The other patch to reorder the priority of the .ready files could go
> down without any problem though.

Glad to hear it.

-- 
-David
david@pgmasters.net


pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: Change pgarch_readyXlog() to return .history files first
Next
From: Surafel Temesgen
Date:
Subject: START/END line number for COPY FROM