From: Mats Kindahl <mats.kindahl@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: japinli@hotmail.com
Cc: suryapoondla4@gmail.com
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: pg_rewind does not rewind diverging timelines
Date: Wed, 12 Aug 2026 08:14:25 +0200
Message-ID: <d10cd7c4-f82b-4ad2-9e06-4d35f7baca16@gmail.com> (raw)
In-Reply-To: <amaZ6bN0pJM75OEs@paquier.xyz>
References: <SY7PR01MB10921E0F8383139EB27B33C11B6162@SY7PR01MB10921.ausprd01.prod.outlook.com>
<9ce0d2b9-7a41-4a8a-b299-da295bb4514f@gmail.com>
<SY7PR01MB10921F0B09B693C8D5149880EB6152@SY7PR01MB10921.ausprd01.prod.outlook.com>
<20260601.153058.2271004477925758292.horikyota.ntt@gmail.com>
<amaZ6bN0pJM75OEs@paquier.xyz>
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.
>
>> 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.
Even with a shared archive, it is impossible to ensure such things. It
is a normal consensus problem, and there are just to many ways that it
can go wrong. I think the UUID should not be looked on as a replacement
for the TLI but rather as an an extra protection against problems. It
will ensure that we cannot even accidentally pick the wrong "version" of
the timeline, but keep the simplicity of using TLI for anything else.
> 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.
It will serve as an extra check to ensure that you do not pick the wrong
version of a timeline, similar to how checksums ensure that you are not
using a page that is corrupt.
Best wishes,
Mats Kindahl, Multigres team, Supabase
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: mats.kindahl@gmail.com, michael@paquier.xyz, horikyota.ntt@gmail.com, japinli@hotmail.com, suryapoondla4@gmail.com, pgsql-hackers@lists.postgresql.org
Subject: Re: pg_rewind does not rewind diverging timelines
In-Reply-To: <d10cd7c4-f82b-4ad2-9e06-4d35f7baca16@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox