Message-ID: <d10cd7c4-f82b-4ad2-9e06-4d35f7baca16@gmail.com>
Date: Wed, 12 Aug 2026 08:14:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: pg_rewind does not rewind diverging timelines
To: Michael Paquier <michael@paquier.xyz>,
 Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: japinli@hotmail.com, suryapoondla4@gmail.com,
 pgsql-hackers@lists.postgresql.org
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>
Content-Language: en-US
From: Mats Kindahl <mats.kindahl@gmail.com>
In-Reply-To: <amaZ6bN0pJM75OEs@paquier.xyz>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/d10cd7c4-f82b-4ad2-9e06-4d35f7baca16%40gmail.com>
Precedence: bulk

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