public inbox for [email protected]  

help / color / mirror / Atom feed

From: Chao Li <[email protected]>
To: Japin Li <[email protected]>
Cc: Jack Bonatakis <[email protected]>
Cc: [email protected]
Subject: Re: Fix a server crash problem from pg_get_database_ddl
Date: Thu, 16 Apr 2026 09:35:39 +0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <SY7PR01MB109214566B069E9C9084590FEB6232@SY7PR01MB10921.ausprd01.prod.outlook.com>
References: <[email protected]>
	<[email protected]>
	<SY7PR01MB109214566B069E9C9084590FEB6232@SY7PR01MB10921.ausprd01.prod.outlook.com>



> On Apr 16, 2026, at 09:23, Japin Li <[email protected]> wrote:
> 
> On Wed, 15 Apr 2026 at 20:44, "Jack Bonatakis" <[email protected]> wrote:
>> I have reproduced this error against the current master:
>> 
>> ```
>> CREATE TABLESPACE ts1 LOCATION '/workspace/tablespaces/pg_bug_ts1';
>> CREATE DATABASE db1 TABLESPACE ts1;
>> DELETE FROM pg_tablespace WHERE spcname = 'ts1';
>> SELECT * FROM pg_get_database_ddl('db1'::regdatabase);
>> 
>> server closed the connection unexpectedly
>> This probably means the server terminated abnormally
>> before or while processing the request.
>> The connection to the server was lost. Attempting reset: Failed.
>> ```
>> Backend logs show:
>> 
>> ```
>> [1] LOG:  client backend (PID 15420) was terminated by signal 11: Segmentation fault
>> [1] DETAIL:  Failed process was running: SELECT * FROM pg_get_database_ddl('db1'::regdatabase);
>> [1] LOG:  terminating any other active server processes
>> ```
>> After applying the patch:
>> 
>> ```
>> SELECT * FROM pg_get_database_ddl('db1'::regdatabase);
>> ERROR:  tablespace with OID 16393 does not exist
>> HINT:  To recover, try ALTER DATABASE ... SET TABLESPACE ... to a valid tablespace.
>> ```
>> and backend logs show:
>> 
>> ```
>> [56] ERROR:  tablespace with OID 16393 does not exist
>> [56] HINT:  To recover, try ALTER DATABASE ... SET TABLESPACE ... to a valid tablespace.
>> [56] STATEMENT:  SELECT * FROM pg_get_database_ddl('db1'::regdatabase);
>> ```
>> All tests pass.
>> 
>> The only note I'd have on the code change is that there is no accompanying test. It seems like a TAP test would be
>> reasonable, but I am quite new and will defer to whether you think that's the right call or even necessary. 
>> 
>> Jack
> 
> This seems similar to [1]. Could you please confirm?
> 
> [1] https://www.postgresql.org/message-id/CAJTYsWXcd324VELk%3D9KdsfTsua9So3Yexqv7N3B23h9zAUD40g%40mail.g....
> 
> -- 
> Regards,
> Japin Li
> ChengDu WenWu Information Technology Co., Ltd.
> 
> 

Thanks for printing out that. Yes, they are similar.

I agree with what Tom said in [2]:
```
This is not a bug. This is a superuser intentionally breaking
the system by corrupting the catalogs. There are any number
of ways to cause trouble with ill-advised manual updates to a
catalog table. Try, eg, "DELETE FROM pg_proc" (... but not in
a database you care about).
```

So, let me take back this patch.

[2] https://www.postgresql.org/message-id/[email protected]

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

view thread (10+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Fix a server crash problem from pg_get_database_ddl
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox