Re: Add timeline to partial WAL segments

From: David Steele <david(at)pgmasters(dot)net>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add timeline to partial WAL segments
Date: 2018-12-20 12:13:01
Message-ID: c615e1a4-04d8-c7d0-c252-fb3e6b874b28@pgmasters.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)pgmasters(dot)net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Surafel Temesgen 2018-12-20 13:02:11 START/END line number for COPY FROM
Previous Message David Steele 2018-12-20 11:57:30 Re: Change pgarch_readyXlog() to return .history files first