Re: [BUG] recovery of prepared transactions during promotion can fail

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Julian Markwort <julian(dot)markwort(at)cybertec(dot)at>
Cc: Nathan Bossart <nathandbossart(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [BUG] recovery of prepared transactions during promotion can fail
Date: 2023-06-21 10:12:12
Message-ID: ZJLM/KLQho86kJBp@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 21, 2023 at 11:11:55AM +0200, Julian Markwort wrote:
> I see you've already undone it.
> Attached is a patch for 009_twophase.pl to just try this corner case at the very end, so as not to influence other
> existing tests in suite.
>
> When I run this on REL_14_8 I get the error again, sort of as a sanity check...

+$cur_primary->enable_archiving;

enable_archiving is a routine aimed at being used internally by
Cluster.pm, so this does not sound like a good idea to me.

Relying on a single node to avoid the previous switchover problem is a
much better idea than what I have tried, but wouldn't it be better to
just move the new test to a separate script and parallelize more? The
runtime of 009_twophase.pl is already quite long.

It is worth noting that I am not going to take any bets with the
buildfarm before 16beta2. Doing that after REL_16_STABLE is created
will limit the risks.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2023-06-21 10:28:28 Re: RFC: logical publication via inheritance root?
Previous Message Nishant Sharma 2023-06-21 09:46:42 Re: postgres_fdw: wrong results with self join + enable_nestloop off