Re: find_all_inheritors() with NoLock fails on concurrently dropped sub-partitions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: find_all_inheritors() with NoLock fails on concurrently dropped sub-partitions
Date: 2026-10-13 18:35:52
Message-ID: 736636.1791916552@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> writes:
> find_all_inheritors() with NoLock doesn't lock anything below the
> given relation, but it still calls find_inheritance_children() on
> every relation it found, which starts with has_subclass(), and that
> errors out if the pg_class row is gone:

I think the assumption is that NoLock should only be used if the
caller already got a lock on the whole inheritance tree. So
I would blame the callers that are not doing that, rather than
squishy-fying find_all_inheritors' semantics. This seems quite
horrid:

> The attached patch makes find_inheritance_children_extended() return
> an empty list if the relation is gone, instead of erroring out.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Manu 2026-10-13 18:37:28 Re: [PG19] Bugs found comparing 19 with 18, list before I open threads
Previous Message Tom Lane 2026-10-13 18:30:13 Re: [PG19] psql backslash commands fail with translated messages and a non UTF-8 client encoding