Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE

Hi,

On Mon, Apr 27, 2026 at 01:36:00AM -0700, Bharath Rupireddy wrote:
> Hi,
>
> On Sun, Apr 26, 2026 at 8:45 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> >
> > > I prefer adding the new struct to carry both table_infos and the
> > > current index into it with the current value-per-call SRF function,
> > > unless others have better ideas.
> >
> > +1. It is simpler than the Materialization concept.
> >
> > > If okay, I will send a new patch
> > > soon. Thank you!
> >
> > Sure, Thanks!
>
> Attached v2 patch. I also refactored the test a bit. Please review. Thank you!

Thanks!

I've 2 comments:

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.

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?

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com