Message-ID: <deb64462-9259-4e1b-af96-8b4678b773a4@gmail.com>
Date: Tue, 2 Jun 2026 04:13:45 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: pg_rewind does not rewind diverging timelines
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, japinli@hotmail.com
Cc: 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>
Content-Language: en-US
From: Mats Kindahl <mats.kindahl@gmail.com>
In-Reply-To: <20260601.153058.2271004477925758292.horikyota.ntt@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/deb64462-9259-4e1b-af96-8b4678b773a4%40gmail.com>
Precedence: bulk

On 6/1/26 08:30, Kyotaro Horiguchi wrote:
> Sorry, I only just noticed this thread.
>
> I may be missing something, but UUID feels somewhat heavyweight to me
> for this problem.
>
> 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.
> 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.

It is a good idea, but unfortunately there are positions in the timeline 
that have same TLI, same LSN, but are still different timelines because 
they originate from different promotions.

Just to summarize the situation: the timeline history file contains a 
TLI (which is a number), and a switchpoint (which is an LSN). Each time 
pg_promote is called, a new timeline is created based on the previous 
TLI (it is increased by 1) and the LSN at that point. (The actual 
history file is written by StartupXLOG, not by pg_promote, but 
pg_promote triggers the process by writing a marker file.)

If two servers go through the same sequence, e.g., start at the same 
timeline, does a promote, and write same length but different data 
(e.g., add a line to a table, but with different contents), they might 
end up with same TLI, same LSN, but different pg_promote calls, and 
different database contents, hence it is not possible to distinguish them.

LSNs are usually different, so it is not a very likely scenario, but it 
is still there.

The UUID is just generated and written when pg_promote is called, which 
is not very often, hence does not affect the server and replication very 
often. Note that the UUID is _not_ in the EOR (EndOfRecovery) record, 
just in the timeline history file.

Best wishes,
Mats Kindahl