Fix a server crash problem from pg_get_database_ddl - Mailing list pgsql-hackers

From Chao Li
Subject Fix a server crash problem from pg_get_database_ddl
Date
Msg-id 573E45C1-31A4-4885-A00C-1A2171159A2A@gmail.com
Whole thread
Responses Re: Fix a server crash problem from pg_get_database_ddl
List pgsql-hackers
Hi,

While doing some testing, I hit a server crash:
```
2026-04-15 11:30:17.377 CST [98179] LOG:  client backend (PID 41260) was terminated by signal 11: Segmentation fault:
11
2026-04-15 11:30:17.377 CST [98179] DETAIL:  Failed process was running: SELECT * FROM
pg_get_database_ddl('db1'::regdatabase);
2026-04-15 11:30:17.377 CST [98179] LOG:  terminating any other active server processes
2026-04-15 11:30:17.380 CST [44361] FATAL:  the database system is in recovery mode
```

After debugging it, I found that the crash happened because I had mistakenly deleted the tablespace entry directly from
pg_tablespace,and pg_get_database_ddl_internal() calls get_tablespace_name() without checking whether the return value
isNULL. 

So this doesn't seem like a bug a normal user could hit. It is more like a superuser-only mistake that creates an
invalidcatalog state. I think that even in such an edge case, we should raise a proper error instead of crashing the
backend.

BTW, I have verified that in this case, ALTER DATABASE ... SET TABLESPACE can move the database to a valid tablespace
andrecover from the issue. 

This patch fixes that by checking for a NULL result and throwing an error.

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





Attachment

pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Support EXCEPT for TABLES IN SCHEMA publications
Next
From: Amit Langote
Date:
Subject: Re: Eliminating SPI / SQL from some RI triggers - take 3