Hi Mats, On Tue, Aug 12, 2026, Mats Kindahl wrote: > Even with a shared archive, it is impossible to ensure such things. It > is a normal consensus problem.
This race came up again in an open-space discussion here. What do you think about allowing a promotion request to supply the new TimelineID? In managed HA setups, the tool that decides which node may promote normally already has a DCS. It could allocate the TLI through the DCS while selecting the new primary, then pass it to PostgreSQL. PostgreSQL would still validate that it is greater than the current TLI and does not conflict with any history file it can see. This would prevent the collision when such a coordinator exists, while the UUID could remain a last-resort check for uncoordinated promotions. archive_command and restore_command are file-transfer interfaces. They cannot express an atomic allocation, so they seem like the wrong place to solve the distributed problem of choosing an identifier. At least until PostgreSQL gets built-in Paxos. Every joke contains a grain of joke, though; Kostya Osipov's related built-in consensus thread is [0]. Would this fit the model you have in mind? Thank you! Best regards, Andrey Borodin. [0] https://www.postgresql.org/message-id/flat/Z_1Cq7JvabsFYjQo%40ark
