Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE

From: shveta malik <shveta(dot)malik(at)gmail(dot)com>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, shveta malik <shveta(dot)malik(at)gmail(dot)com>
Subject: Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE
Date: 2026-04-23 11:15:11
Message-ID: CAJpy0uBRF8szB7BH41yx00V+vhAuSv-2hBcDKO8RHH1skKHNdA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 23, 2026 at 1:01 AM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>
> Hi,
>
> I came across a race condition in pg_get_publication_tables with
> concurrent DROP TABLE. pg_get_publication_tables collects table OIDs
> without locks on the first call, then opens each table on later calls.
> If a table is dropped in between, the function errors with "could not
> open relation with OID".
>

I agree with the problem statement, this is a weird error:

postgres=# select * from pg_publication_tables;
ERROR: could not open relation with OID 16390

> This is common in environments where many tables are being created and
> dropped while pg_publication_tables is queried, such as with FOR ALL
> TABLES publications.
> Please find the attached patch that fixes this by skipping
> concurrently dropped tables instead of erroring out. Tables created
> after the list is built are simply not present in the result set,
> which is expected point-in-time behavior with no error.

I too think that this should be fixed by skipping the dropped table.
Will reveiw patch soon.

thanks
Shveta

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mihail Nikalayeu 2026-04-23 11:43:18 Re: Adding REPACK [concurrently]
Previous Message Alvaro Herrera 2026-04-23 11:01:57 Re: Adding REPACK [concurrently]