Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE

Hi,

On Thu, Jul 23, 2026 at 11:22 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> The patches look mostly good to me. I have a few minor comments:

Thanks for reviewing!

> +session s1
> +# Hold an ACCESS EXCLUSIVE lock on the table in a separate session, so that
> +# the pg_publication_tables query will block when it tries to open the table.
> +step lock { BEGIN; LOCK pubdrop.dropme IN ACCESS EXCLUSIVE MODE; }
> +# Drop the table in the lock-holding session and commit, releasing the lock.
> +step drop_and_commit { DROP TABLE pubdrop.dropme; COMMIT; }
>
> ISTM it's clearer if we write these comments to the permutation since
> we might add more tests in the future that might reuse these steps.

Agreed, and moved the bug and test description above the permutation.
I left the spec file name as-is. It gives flexibility to add more
concurrent-drop related tests (for example, concurrent partition table
drops), and I don't think renaming it to a generic name is the right
choice without knowing exactly what future tests could be added here.

> ---
> +session s2
> +step query
> +{
> + SELECT tablename FROM pg_publication_tables
> + WHERE pubname = 'pub_all' AND schemaname = 'pubdrop'
> + ORDER BY tablename;
> +}
>
> I guess it's better to call pg_get_publication_tables() directly
> instead of via pg_publication_tables. =

Yes, using the pg_get_publication_tables function tests its output
directly, without the join to pg_class that the pg_publication_tables
view adds, which would otherwise filter out the concurrently dropped
table.

Please find the attached v10 patches.

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