Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE

On Fri, Jul 3, 2026 at 10:27 PM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>
> Hi,
>
> On Tue, Jun 30, 2026 at 10:38 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> >
> > While changes to pg_get_publication_tables() look good to me,
>
> Thanks for reviewing!
>
> > I think
> > the regression tests should be implemented as an isolation test rather
> > than a TAP test in 100_bugs.pl as it can be tested without subscribers
> > and the isolation test works well for this kind of race condition
> > tests.
>
> Agreed. The isolation test avoids the extra publisher start/stop the
> TAP version needed, and it's about the same amount of code. Please
> find the attached v9 patches.

Thank you for updating the patches!

The patches look mostly good to me. I have a few minor comments:

+session s1
+# Hold an ACCESS EXCLUSIVE lock on the table in a separate session, so that
+# the pg_publication_tables query will block when it tries to open the table.
+step lock { BEGIN; LOCK pubdrop.dropme IN ACCESS EXCLUSIVE MODE; }
+# Drop the table in the lock-holding session and commit, releasing the lock.
+step drop_and_commit { DROP TABLE pubdrop.dropme; COMMIT; }

ISTM it's clearer if we write these comments to the permutation since
we might add more tests in the future that might reuse these steps.

---
+session s2
+step query
+{
+ SELECT tablename FROM pg_publication_tables
+ WHERE pubname = 'pub_all' AND schemaname = 'pubdrop'
+ ORDER BY tablename;
+}

I guess it's better to call pg_get_publication_tables() directly
instead of via pg_publication_tables. =

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com