Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE

Hi,

On Mon, Apr 27, 2026 at 09:21:54PM -0700, Bharath Rupireddy wrote:
> Hi,
>
> On Mon, Apr 27, 2026 at 8:59 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> >
> > > I initially considered an injection point but chose polling since the
> > > TAP test reproduced the bug consistently with hundreds of tables on my
> > > dev system. I've now added an injection point for predictability.
> > >
> > > I adjusted the commit message a bit. Please find the attached v3 patch
> > > for further review. Thank you!

Thanks for the new version!

> > Thanks Bharath. I have just one minor comment:
> >
> > + INJECTION_POINT("pg-get-publication-tables-build-list", NULL);
> >
> > Shall we name it as 'pg-get-publication-tables-list-built' to be more
> > meaningful, as we are pausing after list is built.
>
> Sure. How about pg-get-publication-tables-after-list-built? It's 42
> bytes, under the INJ_NAME_MAXLEN of 64 bytes, but meaningful.

That looks ok to me.

Just still 2 minor comments:

1/
+ # Drop the table while the SRF is paused.

s/the SRF/ pg_get_publication_tables()/ ?

2/

+# pg_get_publication_tables race with concurrent DROP TABLE.

What about describing a bit more the bug? The other tests in 100_bugs.pl describe
the bug they're testing.

Regards,

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