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 is NULL.

So this doesn't seem like a bug a normal user could hit. It is more like a 
superuser-only mistake that creates an invalid catalog 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 and recover 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: v1-0001-ddlutils-error-out-when-pg_get_database_ddl-sees-.patch
Description: Binary data

Reply via email to