Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commitc820037

Browse files
committed
Make getObjectDescription robust against dangling amproc type links.
Yoran Heling reported a case where a data type could be droppedwhile references to its OID remain behind in pg_amproc. Thiscauses getObjectDescription to fail, which blocks dropping theoperator family (since our DROP code likes to construct descriptionsof everything it's dropping). The proper fix for this requiresadding more pg_depend entries. But to allow DROP to go through withalready-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 supportedbranches (although the problem may be unreachable in v13).Discussion:https://postgr.es/m/Z1MVCOh1hprjK5Sf@gmai021
1 parent3220cea commitc820037

File tree

1 file changed

+20
-4
lines changed

1 file changed

+20
-4
lines changed

‎src/backend/catalog/objectaddress.c

Lines changed: 20 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -3235,15 +3235,23 @@ getObjectDescription(const ObjectAddress *object, bool missing_ok)
32353235
initStringInfo(&opfam);
32363236
getOpFamilyDescription(&opfam,amopForm->amopfamily, false);
32373237

3238+
/*
3239+
* We use FORMAT_TYPE_ALLOW_INVALID here so as not to fail
3240+
* completely if the type links are dangling, which is a form
3241+
* of catalog corruption that could occur due to old bugs.
3242+
*/
3243+
32383244
/*------
32393245
translator: %d is the operator strategy (a number), the
32403246
first two %s's are data type names, the third %s is the
32413247
description of the operator family, and the last %s is the
32423248
textual form of the operator with arguments. */
32433249
appendStringInfo(&buffer,_("operator %d (%s, %s) of %s: %s"),
32443250
amopForm->amopstrategy,
3245-
format_type_be(amopForm->amoplefttype),
3246-
format_type_be(amopForm->amoprighttype),
3251+
format_type_extended(amopForm->amoplefttype,
3252+
-1,FORMAT_TYPE_ALLOW_INVALID),
3253+
format_type_extended(amopForm->amoprighttype,
3254+
-1,FORMAT_TYPE_ALLOW_INVALID),
32473255
opfam.data,
32483256
format_operator(amopForm->amopopr));
32493257

@@ -3292,15 +3300,23 @@ getObjectDescription(const ObjectAddress *object, bool missing_ok)
32923300
initStringInfo(&opfam);
32933301
getOpFamilyDescription(&opfam,amprocForm->amprocfamily, false);
32943302

3303+
/*
3304+
* We use FORMAT_TYPE_ALLOW_INVALID here so as not to fail
3305+
* completely if the type links are dangling, which is a form
3306+
* of catalog corruption that could occur due to old bugs.
3307+
*/
3308+
32953309
/*------
32963310
translator: %d is the function number, the first two %s's
32973311
are data type names, the third %s is the description of the
32983312
operator family, and the last %s is the textual form of the
32993313
function with arguments. */
33003314
appendStringInfo(&buffer,_("function %d (%s, %s) of %s: %s"),
33013315
amprocForm->amprocnum,
3302-
format_type_be(amprocForm->amproclefttype),
3303-
format_type_be(amprocForm->amprocrighttype),
3316+
format_type_extended(amprocForm->amproclefttype,
3317+
-1,FORMAT_TYPE_ALLOW_INVALID),
3318+
format_type_extended(amprocForm->amprocrighttype,
3319+
-1,FORMAT_TYPE_ALLOW_INVALID),
33043320
opfam.data,
33053321
format_procedure(amprocForm->amproc));
33063322

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp