From: Alexander Lakhin <exclusion@gmail.com>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Yu Shi (Fujitsu) <shiy.fnst@fujitsu.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Thomas Munro <thomas.munro@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Test slots invalidations in 035_standby_logical_decoding.pl only if dead rows are removed
Date: Fri, 12 Jan 2024 14:00:01 +0300
Message-ID: <cc7925b8-30cc-c76d-b1b6-c9ec6bd36a03@gmail.com> (raw)
In-Reply-To: <ZaDnIMTbT+0yR5LZ@ip-10-97-1-34.eu-west-3.compute.internal>
References: <bf67e076-b163-9ba3-4ade-b9fc51a3a8f6@gmail.com>
<d40d015f-03a4-1cf2-6c1f-2b9aca860762@gmail.com>
<28fffded-7dc6-3518-7e0e-fc76b9221586@gmail.com>
<ZZ4cZkBLczQISHxq@paquier.xyz>
<7c025095-5763-17a6-8c80-899b35bd0459@gmail.com>
<ZZ7GpII4bAYN+jT5@ip-10-97-1-34.eu-west-3.compute.internal>
<5d0e5bec-67f9-9164-36cb-c4ff5f95d1ed@gmail.com>
<ZaACEPtVovKlRVUf@ip-10-97-1-34.eu-west-3.compute.internal>
<6f85667e-5754-5d35-dbf1-c83fe08c1e48@gmail.com>
<ZaBlU5FqOeDqyHtJ@paquier.xyz>
<ZaDnIMTbT+0yR5LZ@ip-10-97-1-34.eu-west-3.compute.internal>
Hi,
12.01.2024 10:15, Bertrand Drouvot wrote:
>
> For this one, the "good" news is that it looks like that we don’t see the
> "terminating" message not followed by an "obsolete" message (so the engine
> behaves correctly) anymore.
>
> There is simply nothing related to the row_removal_activeslot at all (the catalog_xmin
> advanced and there is no conflict).
Yes, judging from all the failures that we see now, it looks like the
0001-Fix-race-condition...patch works as expected.
> And I agree that this is due to the Standby/RUNNING_XACTS that is "advancing" the
> catalog_xmin of the active slot.
>
>> Standby/RUNNING_XACTS is exactly why 039_end_of_wal.pl uses wal_level
>> = minimal, because these lead to unpredictible records inserted,
>> impacting the reliability of the tests. We cannot do that here,
>> obviously. That may be a long shot, but could it be possible to tweak
>> the test with a retry logic, retrying things if such a standby
>> snapshot is found because we know that the invalidation is not going
>> to work anyway?
> I think it all depends what the xl_running_xacts does contain (means does it
> "advance" or not the catalog_xmin in our case).
>
> In our case it does advance it (should it occurs) due to the "select txid_current()"
> that is done in wait_until_vacuum_can_remove() in 035_standby_logical_decoding.pl.
>
> I suggest to make use of txid_current_snapshot() instead (that does not produce
> a Transaction/COMMIT wal record, as opposed to txid_current()).
>
> I think that it could be "enough" for our case here, and it's what v5 attached is
> now doing.
>
> Let's give v5 a try? (please apply v1-0001-Fix-race-condition-in-InvalidatePossiblyObsoleteS.patch
> too).
Unfortunately, I've got the failure again (please see logs attached).
(_primary.log can confirm that I have used exactly v5 — I see no
txid_current() calls there...)
Best regards,
Alexander
Attachments:
035-failures-vacuum-pg_authid.tar.gz (application/gzip, 150.7K) 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: exclusion@gmail.com, bertranddrouvot.pg@gmail.com, michael@paquier.xyz, shiy.fnst@fujitsu.com, tgl@sss.pgh.pa.us, robertmhaas@gmail.com, andres@anarazel.de, thomas.munro@gmail.com, pgsql-hackers@lists.postgresql.org
Subject: Re: Test slots invalidations in 035_standby_logical_decoding.pl only if dead rows are removed
In-Reply-To: <cc7925b8-30cc-c76d-b1b6-c9ec6bd36a03@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