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
