> On Apr 16, 2026, at 09:23, Japin Li <japinli@hotmail.com> wrote: > > On Wed, 15 Apr 2026 at 20:44, "Jack Bonatakis" <jack@bonatak.is> 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.gmail.com. > > -- > 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). ```
