Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE - Mailing list pgsql-hackers

On Sat, Apr 25, 2026 at 1:51 AM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> Hi,
>
> On Fri, Apr 24, 2026 at 12:17 AM shveta malik <shveta.malik@gmail.com> wrote:
> >
> > > What about introducing a publication_tables_state struct stored in user_fctx
> > > that carries both the list and a private position index? (kind of what
> > > pg_timezone_abbrevs_zone() is doing).
> >
> > Yeah, that is a good idea. Seems doable.
>
> +1. Thanks for the pointer. Adding a new struct to carry both the
> table_infos and the current index into it seems simple with a smaller
> diff.
>
> If I were to think of another approach (I don't prefer this approach
> anyway), we could convert pg_get_publication_tables from the current
> value-per-call SRF function (SRF_IS_FIRSTCALL + SRF_RETURN_NEXT) to a
> materialized SRF function (InitMaterializedSRF +
> tuplestore_putvalues). With a materialized SRF function, there is no
> need to add a new structure or maintain per-call context - table_infos
> becomes a local variable, and we skip placing anything related to
> dropped tables into the tuplestore immediately in the second loop (the
> first loop remains the same, preparing the table_infos list). This
> approach seems more complex with a larger diff and requires use of
> InitMaterializedSRF for versions >= PG16, SetSingleFuncCall for PG15,
> and for PG14 requires inlining SetSingleFuncCall.
>
> 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!

thanks
Shveta