| From: | Baji Shaik <baji(dot)pgdev(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL-development <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Subject: | Avoid crashes on a concurrently dropped schema |
| Date: | 2026-10-25 15:40:04 |
| Message-ID: | CA+fm-RPD0m9QL8W+804SGBBxn5iFz5wn=kncaP9SkM-s4PUANw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
I noticed two places that can segfault if a schema is dropped while
they run: pg_identify_object(), and schema_to_xml() with the related
SQL/XML functions. Both look up a schema name by OID without holding a
lock on the schema, and dereference the NULL that get_namespace_name()
returns after a concurrent DROP SCHEMA. It's a narrow race and rare in
practice, but any user can hit it, and it takes the cluster through
crash recovery.
0001 makes pg_identify_object() return NULL for the schema, as it
already does for objects that have gone away, so catalog-wide scans
keep working. 0002 makes the single-schema XML functions report
that the schema does not exist, as they do for a nonexistent schema,
and makes database_to_xml* skip it. Both go back to 14.
Thoughts?
Thanks,
Baji Shaik
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Avoid-crash-in-pg_identify_object-on-a-concurrently-.patch | application/octet-stream | 1.6 KB |
| 0002-Avoid-crash-in-schema_to_xml-on-a-concurrently-dropp.patch | application/octet-stream | 3.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | shihao zhong | 2026-10-25 15:56:26 | Re: Skip prefetch for block references that follow a FPW or WILL_INIT of the same block |
| Previous Message | shihao zhong | 2026-10-25 15:36:54 | Re: Avoid truncated or zero-padded copies of replaced files in backups. |