From: Michael Paquier <michael@paquier.xyz>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Cc: exclusion@gmail.com
Subject: Re: Fix race condition in InvalidatePossiblyObsoleteSlot()
Date: Wed, 6 Mar 2024 14:47:55 +0900
Message-ID: <ZegDi9A54TPaIRFp@paquier.xyz> (raw)
In-Reply-To: <ZebxH6YJ8mfB5rJ6@ip-10-97-1-34.eu-west-3.compute.internal>
References: <Zc30i8fB7VYrTVw+@ip-10-97-1-34.eu-west-3.compute.internal>
<ZdLxr2CPpPVNh9Zi@paquier.xyz>
<CALj2ACUMPTvuk0_GuPiFbUb=PMTQq0WMi5Kvj8Mz0JZ_ico1Lw@mail.gmail.com>
<ZdMkJAaF7HcGutE2@ip-10-97-1-34.eu-west-3.compute.internal>
<ZdPpdYBIrDqEl25c@paquier.xyz>
<ZdQ5uDWxzu9O1T03@paquier.xyz>
<ZdTNafYSxwnKNIhj@ip-10-97-1-34.eu-west-3.compute.internal>
<ZdyZya4YrNapWKqz@ip-10-97-1-34.eu-west-3.compute.internal>
<ZeZqbHjLrc8hkIvu@paquier.xyz>
<ZebxH6YJ8mfB5rJ6@ip-10-97-1-34.eu-west-3.compute.internal>
On Tue, Mar 05, 2024 at 10:17:03AM +0000, Bertrand Drouvot wrote:
> On Tue, Mar 05, 2024 at 09:42:20AM +0900, Michael Paquier wrote:
>> First, in a build where 818fefd8fd is included, this makes the test
>> script a lot slower. Most of the logic is quick, but we're spending
>> 10s or so checking that catalog_xmin has advanced. Could it be
>> possible to make that faster?
>
> Yeah, v2 attached changes this. It moves the injection point after the process
> has been killed so that another process can decode at wish (without the need
> to wait for a walsender timeout) to reach LogicalConfirmReceivedLocation().
Ah, OK. Indeed that's much faster this way.
> I try to simulate a revert of 818fefd8fd (replacing "!terminated" by "1 == 1"
> before the initial_* assignements).
Yeah. I can see how this messes up with the calculation of the
conditions, which is enough from my perspective, even if we don't have
any sanity checks in 818fefd8fd originally.
> The issue is that then the new ASSERT is
> triggered leading to the standby shutdown. So, I'm not sure how to improve this
> case.
It's been mentioned recently that we are not good at detecting crashes
in the TAP tests. I am wondering if we should check the status of the
node in the most popular routines of Cluster.pm and die hard, as one
way to make the tests more responsive.. A topic for a different
thread, for sure.
> Done in v2.
Reworded a few things and applied this version.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
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: michael@paquier.xyz, bertranddrouvot.pg@gmail.com, bharath.rupireddyforpostgres@gmail.com, pgsql-hackers@lists.postgresql.org, exclusion@gmail.com
Subject: Re: Fix race condition in InvalidatePossiblyObsoleteSlot()
In-Reply-To: <ZegDi9A54TPaIRFp@paquier.xyz>
* 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