Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE

[Bharath Rupireddy]

Hi,

On Fri, Jun 26, 2026 at 1:31 PM Masahiko Sawada <sawada.m...@gmail.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!

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

v8-0001-Fix-pg_get_publication_tables-race-with-concurren.patch
Description: Binary data

v8-0001-PG18-Fix-pg_get_publication_tables-race-with-conc.patch
Description: Binary data

v8-0001-PG17-Fix-pg_get_publication_tables-race-with-conc.patch
Description: Binary data

v8-0001-PG16-Fix-pg_get_publication_tables-race-with-conc.patch
Description: Binary data