agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedFrom: Mats Kindahl <mats.kindahl@gmail.com>
To: Andreas Karlsson <andreas@proxel.se>
To: Michael Paquier <michael@paquier.xyz>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: japinli@hotmail.com
Cc: suryapoondla4@gmail.com
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: pg_rewind does not rewind diverging timelines
Date: Wed, 12 Aug 2026 08:33:19 +0200
Message-ID: <0bf0971a-d72d-436e-b8aa-b34abdb1c3de@gmail.com> (raw)
In-Reply-To: <49b84ecf-21a2-4e2b-ab66-fbba8ee6540e@proxel.se>
References: <SY7PR01MB10921E0F8383139EB27B33C11B6162@SY7PR01MB10921.ausprd01.prod.outlook.com>
<9ce0d2b9-7a41-4a8a-b299-da295bb4514f@gmail.com>
<SY7PR01MB10921F0B09B693C8D5149880EB6152@SY7PR01MB10921.ausprd01.prod.outlook.com>
<20260601.153058.2271004477925758292.horikyota.ntt@gmail.com>
<amaZ6bN0pJM75OEs@paquier.xyz>
<49b84ecf-21a2-4e2b-ab66-fbba8ee6540e@proxel.se>
On 7/29/26 14:55, Andreas Karlsson wrote:
> 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.
>
> As Ants said, the LSN can easily be the same in both.
>
>>> 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.
>
> Having had to debug issues with pg_rewind and timelines in our
> Kubernetes Operator these UUIDs would probably have helped me a lot.
> Maybe the proposed fix is wrong (maybe like Ants says it does not got
> far enough) but from personal experience I disagree with that there is
> no problem here.
>
> I will try to find time to play around with the patch and see if it
> would have helped us.
Thanks Andreas,
I would love to hear if this would have been a help in those scenarios.
Best wishes,
Mats Kindahl, Multigres team, Supabase
view thread (35+ messages) latest in thread
Message-ID: <0bf0971a-d72d-436e-b8aa-b34abdb1c3de@gmail.com>
Permalink: ../0bf0971a-d72d-436e-b8aa-b34abdb1c3de@gmail.com/
Also on: postgresql.org/message-id/0bf0971a-d72d-436e-b8aa-b34abdb1c3de@gmail.com
reply
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, andreas@proxel.se, michael@paquier.xyz, horikyota.ntt@gmail.com, japinli@hotmail.com, suryapoondla4@gmail.com, pgsql-hackers@lists.postgresql.org
Subject: Re: pg_rewind does not rewind diverging timelines
In-Reply-To: <0bf0971a-d72d-436e-b8aa-b34abdb1c3de@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 agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox