Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE

On Fri, Jun 26, 2026 at 10:49 PM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>
> Hi,
>
> On Fri, Jun 26, 2026 at 1:31 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> >
> > > My earlier argument was that no function returning table OIDs can
> > > guarantee they remain valid - a drop can happen right after we return
> > > the OID, and accuracy is in the caller's hands. All the callers of
> > > pg_get_publication_tables already handle this by JOINing with
> > > pg_class.
> > >
> > > However, a closer look at other functions that either build a list of
> > > table OIDs (expand_partitioned_rtentry) or work on previously built
> > > table OIDs (vacuum_open_relation) proves me wrong - they all account
> > > for concurrent table drops with try_table_open. So, I'm convinced to
> > > add try_table_open in pg_get_publication_tables for all the tables
> > > regardless, unless I'm missing something here.
> >
> > +1
> >
> > > I will drop the tuplestore changes for now and repost them as a
> > > refactoring patch after the PG20 dev branch is cut.
> > >
> > > Thoughts?
> >
> > +1. We can revisit the tuplestore idea for PG20, possibly in a
> > separate thread. For bug fixing, let's focus on making it simple and
> > less invasive.
>
> Please find the attached v8 patches. Thanks!

Thank you for updating the patches!

While changes to pg_get_publication_tables() look good to me, 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.

Regards,

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