Re: pg_rewind does not rewind diverging timelines

From: Andreas Karlsson <andreas(at)proxel(dot)se>
To: Michael Paquier <michael(at)paquier(dot)xyz>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: japinli(at)hotmail(dot)com, mats(dot)kindahl(at)gmail(dot)com, suryapoondla4(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pg_rewind does not rewind diverging timelines
Date: 2026-07-29 12:55:02
Message-ID: 49b84ecf-21a2-4e2b-ab66-fbba8ee6540e@proxel.se
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 7/27/26 01:36, Michael Paquier wrote:
> On Mon, Jun 01, 2026 at 03:30:58PM +0900, Kyotaro Horiguchi wrote:
>> I wonder whether strengthening the history-based matching would be
>> sufficient instead. If timelines with the same TLI but different
>> histories can be treated as distinct and pg_rewind continues walking
>> the history chain until it finds a common ancestor, that seems like a
>> fairly natural fit with the existing timeline model.
>
> Yeah, perhaps there is something that we could do here better in
> pg_rewind in terms of TLI history. A second software layer to ensure
> TLI unicity feels just like a shortcut: we already have a LSN.

As Ants said, the LSN can easily be the same in both.

>> UUIDs would certainly make identification straightforward, although
>> they would also introduce longer identifiers that are a bit less
>> convenient for humans to work with. My initial thought is that it may
>> be worth exploring how far we can get with the existing history
>> information before introducing a new identifier.
>
> This. For this reason, I am not convinced that this proposal is
> neither acceptable or something that we need to do at all.
>
> Why should we bear the burden of introducing a second level of
> timeline identification knowing that by design we have to rely on a
> *single* archive location for a new timeline selection when a standby
> is triggered for promotion? My opinion is that this is trying to fix
> a problem for something that it not actually a problem. If you play
> with HA scenarios where there is a risk of two standbys reusing the
> same timeline number, just don't do that. We've historically claimed
> that the archive strategy is wrong if your deployments cannot
> guarantee a unique TLI assignment. A new sub-identification system
> will not provide more guarantees.

Having had to debug issues with pg_rewind and timelines in our
Kubernetes Operator these UUIDs would probably have helped me a lot.
Maybe the proposed fix is wrong (maybe like Ants says it does not got
far enough) but from personal experience I disagree with that there is
no problem here.

I will try to find time to play around with the patch and see if it
would have helped us.

--
Andreas Karlsson
Percona

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry Fomin 2026-07-29 13:45:48 Re: [PATCH v1 0/7] Wait event timing and tracing instrumentation
Previous Message wenhui qiu 2026-07-29 12:47:49 Re: Prove a NOT IN's left-hand expressions non-nullable from quals