From: Mats Kindahl <mats.kindahl@gmail.com>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Japin Li <japinli@hotmail.com>
Cc: pgsql-hackers mailing list <pgsql-hackers@lists.postgresql.org>
Subject: Re: pg_rewind does not rewind diverging timelines
Date: Thu, 3 Sep 2026 21:21:41 +0200
Message-ID: <5407e386-3d61-4712-99af-9d0b29fab3b2@gmail.com> (raw)
In-Reply-To: <80EEB51E-176C-4E57-B86F-5200F4348D02@yandex-team.ru>
References: <CAN305gBeJr8m7ZRW9mH0zakEFR4hDUPDo8fJRKJOHWMORG5_Bg@mail.gmail.com>
<80D76C66-A953-466C-8295-A1CF8365A4D2@yandex-team.ru>
<10351a09-3a93-49fc-a366-d616b67c6ede@gmail.com>
<SY7PR01MB10921220B1B7054260BC8031FB6C62@SY7PR01MB10921.ausprd01.prod.outlook.com>
<e486bdcd-4e97-4e6a-ba3d-b4eb720fe62f@gmail.com>
<80EEB51E-176C-4E57-B86F-5200F4348D02@yandex-team.ru>
Hi Andrey, and thank you for the comments.
On 8/30/26 19:35, Andrey Borodin wrote:
> 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.
If we have some sort of API or callback for assigning a new TLI that
would be excellent. Would be useful for a bunch of DCS as a way to
ensure that you do not pick a conflicting TLI. Should probably be
configurable though, but a normal hook callback would probably be
sufficient... and yes, the UUID is good to have as a last-resort check
to ensure that you don't break things.
>
> 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.
Yup, agree.
>
> 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 love to see that. Kostja would definitely know how to implement
that. :)
>
> Would this fit the model you have in mind?
That would work fine. My main concern about adding UUIDs were to prevent
problems when you accidentally allocate same TLI to timelines that are
not the same. Integration hooks with a DCS would be icing on the cake. :)
Best wishes,
Mats Kindahl
>
> Thank you!
>
>
> Best regards, Andrey Borodin.
>
> [0]https://www.postgresql.org/message-id/flat/Z_1Cq7JvabsFYjQo%40ark
>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: mats.kindahl@gmail.com, x4mmm@yandex-team.ru, japinli@hotmail.com, pgsql-hackers@lists.postgresql.org
Subject: Re: pg_rewind does not rewind diverging timelines
In-Reply-To: <5407e386-3d61-4712-99af-9d0b29fab3b2@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox