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
signature.asc
Description: PGP signature
