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-12 12:54:05
Message-ID: 3dc9ee73-8197-953b-7347-99ed06dcbcd4@pgmasters.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/12/18 12:14 AM, Michael Paquier wrote:
> On Tue, Dec 11, 2018 at 11:27:30PM -0500, David Steele wrote:
>> And yeah, I'm not sure that I'm totally sold on this idea either, but I
>> wanted to get a conversation going.
>
> Another idea which I think we could live with is to embed within the
> segment file name the LSN switch point, in a format consistent with
> backup history files. And as a bonus it could be used for sanity
> checks.

The LSN switch point is often the same even when servers are going to
different timelines. If the LSN is different enough then the problem
solves itself since the .partial will be on an entirely different segment.

But, we could at least use the . notation and end up with something like
000000010000000100000001.00000002.partial or perhaps
000000010000000100000001.T00000002.partial? Maybe
000000010000000100000001.00000002.tpartial?

I can't decide whether the .partial files generated by pg_receivewal are
a problem or not. It seems to me that only the original cluster is
going to be able to stream this file -- once the segment is renamed to
.partial it won't be visible to pg_receivexlog. So, .partial without a
timeline extension just means partial from the original timeline.

There's another difference. The .partial generated by pg_receivewal is
an actively-worked-on file whereas the .partial generated by a promotion
is probably headed for oblivion. I haven't see a single case where one
was used in an actual recovery (which doesn't mean it hasn't happened,
of course).

> (I am completely sold to the idea of prioritizing file types in the
> archiver.)

OK, I'll work up a patch for that, then. It doesn't solve the .partial
problem, but it does reduce the likelihood that two servers will end up
on the same timeline.

--
-David
david(at)pgmasters(dot)net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2018-12-12 13:01:18 Re: Updated backup APIs for non-exclusive backups
Previous Message Amit Kapila 2018-12-12 12:38:20 Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query