| 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
| 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] |