Re: Avoid crashes on a concurrently dropped schema

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Baji Shaik <baji(dot)pgdev(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>
Subject: Re: Avoid crashes on a concurrently dropped schema
Date: 2026-10-31 11:47:32
Message-ID: 80287807-1194-4606-b5f4-7bdc090cd730@iki.fi
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 25/10/2026 17:40, Baji Shaik wrote:
> 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.

Committed down to v14, thanks!

- Heikki

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhijie Hou 2026-10-31 12:35:15 Re: Add a hook for handling logical decoding messages on subscribers.
Previous Message Chao Li 2026-10-31 11:36:43 Re: Fix error handling in pg_flush_data() and FilePrefetch()