database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-05-28 05:21:27 +03:00
Code

Make getObjectDescription robust against dangling amproc type links.

Browse Source 
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
This commit is contained in:
Tom Lane 2024-12-07 14:28:16 -05:00
parent 765f76d8cd
commit 5b44a317ae
1 changed files with 20 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
src/backend/catalog/objectaddress.c
View File

@ -3230,6 +3230,12 @@ getObjectDescription(const ObjectAddress *object, bool missing_ok)
initStringInfo(&opfam);
getOpFamilyDescription(&opfam, amopForm->amopfamily, false);
/*
* We use FORMAT_TYPE_ALLOW_INVALID here so as not to fail
* completely if the type links are dangling, which is a form
* of catalog corruption that could occur due to old bugs.
*/
/*------
translator: %d is the operator strategy (a number), the
first two %s's are data type names, the third %s is the
@ -3237,8 +3243,10 @@ getObjectDescription(const ObjectAddress *object, bool missing_ok)
textual form of the operator with arguments. */
appendStringInfo(&buffer, _("operator %d (%s, %s) of %s: %s"),
amopForm->amopstrategy,
format_type_be(amopForm->amoplefttype),
format_type_be(amopForm->amoprighttype),
format_type_extended(amopForm->amoplefttype,
-1, FORMAT_TYPE_ALLOW_INVALID),
format_type_extended(amopForm->amoprighttype,
-1, FORMAT_TYPE_ALLOW_INVALID),
opfam.data,
format_operator(amopForm->amopopr));
@ -3287,6 +3295,12 @@ getObjectDescription(const ObjectAddress *object, bool missing_ok)
initStringInfo(&opfam);
getOpFamilyDescription(&opfam, amprocForm->amprocfamily, false);
/*
* We use FORMAT_TYPE_ALLOW_INVALID here so as not to fail
* completely if the type links are dangling, which is a form
* of catalog corruption that could occur due to old bugs.
*/
/*------
translator: %d is the function number, the first two %s's
are data type names, the third %s is the description of the
@ -3294,8 +3308,10 @@ getObjectDescription(const ObjectAddress *object, bool missing_ok)
function with arguments. */
appendStringInfo(&buffer, _("function %d (%s, %s) of %s: %s"),
amprocForm->amprocnum,
format_type_be(amprocForm->amproclefttype),
format_type_be(amprocForm->amprocrighttype),
format_type_extended(amprocForm->amproclefttype,
-1, FORMAT_TYPE_ALLOW_INVALID),
format_type_extended(amprocForm->amprocrighttype,
-1, FORMAT_TYPE_ALLOW_INVALID),
opfam.data,
format_procedure(amprocForm->amproc));