Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE
Date
Msg-id CALj2ACWT0bT3Nr3FtW=9w0y6nbtt_yx9sqNsKyv4GeYmhsaU_Q@mail.gmail.com
Whole thread
In response to Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
Responses Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE
List pgsql-hackers
Hi,

On Mon, Apr 27, 2026 at 3:01 AM Bertrand Drouvot
<bertranddrouvot.pg@gmail.com> wrote:
>
> I've 2 comments:

Thank you for reviewing!

> 1/ What about having just one curr_idx increment? (right after list_nth(),
> before the skip checks). I think that would be less error-prone if new skip
> conditions are added later.

Done.

> 2/ I think that the test is racy and could also succeed even without the fixes.
> Indeed, I think that the drops can complete before any concurrent polling
> happens (I can see it by adding a pg_sleep(2) before the first poll in the DO
> block). What about using an injection point to ensure a relation is removed
> during the polling?

I initially considered an injection point but chose polling since the
TAP test reproduced the bug consistently with hundreds of tables on my
dev system. I've now added an injection point for predictability.

I adjusted the commit message a bit. Please find the attached v3 patch
for further review. Thank you!

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com

Attachment

pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: [Proposal] pg_stat_wal_records – per-record-type WAL generation statistics
Next
From: Peter Smith
Date:
Subject: Re: Redundant/mis-use of _(x) gettext macro?