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

Commit5b44a31

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 parent765f76d commit5b44a31

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
@@ -3230,15 +3230,23 @@ getObjectDescription(const ObjectAddress *object, bool missing_ok)
32303230
initStringInfo(&opfam);
32313231
getOpFamilyDescription(&opfam,amopForm->amopfamily, false);
32323232

3233+
/*
3234+
* We use FORMAT_TYPE_ALLOW_INVALID here so as not to fail
3235+
* completely if the type links are dangling, which is a form
3236+
* of catalog corruption that could occur due to old bugs.
3237+
*/
3238+
32333239
/*------
32343240
translator: %d is the operator strategy (a number), the
32353241
first two %s's are data type names, the third %s is the
32363242
description of the operator family, and the last %s is the
32373243
textual form of the operator with arguments. */
32383244
appendStringInfo(&buffer,_("operator %d (%s, %s) of %s: %s"),
32393245
amopForm->amopstrategy,
3240-
format_type_be(amopForm->amoplefttype),
3241-
format_type_be(amopForm->amoprighttype),
3246+
format_type_extended(amopForm->amoplefttype,
3247+
-1,FORMAT_TYPE_ALLOW_INVALID),
3248+
format_type_extended(amopForm->amoprighttype,
3249+
-1,FORMAT_TYPE_ALLOW_INVALID),
32423250
opfam.data,
32433251
format_operator(amopForm->amopopr));
32443252

@@ -3287,15 +3295,23 @@ getObjectDescription(const ObjectAddress *object, bool missing_ok)
32873295
initStringInfo(&opfam);
32883296
getOpFamilyDescription(&opfam,amprocForm->amprocfamily, false);
32893297

3298+
/*
3299+
* We use FORMAT_TYPE_ALLOW_INVALID here so as not to fail
3300+
* completely if the type links are dangling, which is a form
3301+
* of catalog corruption that could occur due to old bugs.
3302+
*/
3303+
32903304
/*------
32913305
translator: %d is the function number, the first two %s's
32923306
are data type names, the third %s is the description of the
32933307
operator family, and the last %s is the textual form of the
32943308
function with arguments. */
32953309
appendStringInfo(&buffer,_("function %d (%s, %s) of %s: %s"),
32963310
amprocForm->amprocnum,
3297-
format_type_be(amprocForm->amproclefttype),
3298-
format_type_be(amprocForm->amprocrighttype),
3311+
format_type_extended(amprocForm->amproclefttype,
3312+
-1,FORMAT_TYPE_ALLOW_INVALID),
3313+
format_type_extended(amprocForm->amprocrighttype,
3314+
-1,FORMAT_TYPE_ALLOW_INVALID),
32993315
opfam.data,
33003316
format_procedure(amprocForm->amproc));
33013317

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp