aboutsummaryrefslogtreecommitdiff
path: root/src/backend/tcop/postgres.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2024-12-07 14:28:16 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2024-12-07 14:28:16 -0500
commitfaad0183507b9185382b0ab6f7701144b8cc5687 (patch)
tree0777725615463da583c4a14d12bfa227158fff20 /src/backend/tcop/postgres.c
parent26c233b8b8f536f4ed252f9145c2ee365bb04b99 (diff)
downloadpostgresql-faad0183507b9185382b0ab6f7701144b8cc5687.tar.gz
postgresql-faad0183507b9185382b0ab6f7701144b8cc5687.zip
Make getObjectDescription robust against dangling amproc type links.
Yoran Heling reported a case where a data type could be dropped while references to its OID remain behind in pg_amproc. This causes getObjectDescription to fail, which blocks dropping the operator family (since our DROP code likes to construct descriptions of everything it's dropping). The proper fix for this requires adding more pg_depend entries. But to allow DROP to go through with already-corrupt catalogs, tweak getObjectDescription to print "???" for the type instead of failing when it processes such an entry. I changed the logic for pg_amop similarly, for consistency, although it is not known that the problem can manifest in pg_amop. Per report from Yoran Heling. Back-patch to all supported branches (although the problem may be unreachable in v13). Discussion: https://postgr.es/m/Z1MVCOh1hprjK5Sf@gmai021
Diffstat (limited to 'src/backend/tcop/postgres.c')
0 files changed, 0 insertions, 0 deletions