On Fri, Jun 26, 2026 at 10:49 PM Bharath Rupireddy <[email protected]> wrote: > > Hi, > > On Fri, Jun 26, 2026 at 1:31 PM Masahiko Sawada <[email protected]> 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
