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. 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.
--
Michael
