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

Commit531cbd8

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 parentf2eba40 commit531cbd8

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
@@ -3052,15 +3052,23 @@ getObjectDescription(const ObjectAddress *object)
30523052
initStringInfo(&opfam);
30533053
getOpFamilyDescription(&opfam,amopForm->amopfamily);
30543054

3055+
/*
3056+
* We use FORMAT_TYPE_ALLOW_INVALID here so as not to fail
3057+
* completely if the type links are dangling, which is a form
3058+
* of catalog corruption that could occur due to old bugs.
3059+
*/
3060+
30553061
/*------
30563062
translator: %d is the operator strategy (a number), the
30573063
first two %s's are data type names, the third %s is the
30583064
description of the operator family, and the last %s is the
30593065
textual form of the operator with arguments. */
30603066
appendStringInfo(&buffer,_("operator %d (%s, %s) of %s: %s"),
30613067
amopForm->amopstrategy,
3062-
format_type_be(amopForm->amoplefttype),
3063-
format_type_be(amopForm->amoprighttype),
3068+
format_type_extended(amopForm->amoplefttype,
3069+
-1,FORMAT_TYPE_ALLOW_INVALID),
3070+
format_type_extended(amopForm->amoprighttype,
3071+
-1,FORMAT_TYPE_ALLOW_INVALID),
30643072
opfam.data,
30653073
format_operator(amopForm->amopopr));
30663074

@@ -3102,15 +3110,23 @@ getObjectDescription(const ObjectAddress *object)
31023110
initStringInfo(&opfam);
31033111
getOpFamilyDescription(&opfam,amprocForm->amprocfamily);
31043112

3113+
/*
3114+
* We use FORMAT_TYPE_ALLOW_INVALID here so as not to fail
3115+
* completely if the type links are dangling, which is a form
3116+
* of catalog corruption that could occur due to old bugs.
3117+
*/
3118+
31053119
/*------
31063120
translator: %d is the function number, the first two %s's
31073121
are data type names, the third %s is the description of the
31083122
operator family, and the last %s is the textual form of the
31093123
function with arguments. */
31103124
appendStringInfo(&buffer,_("function %d (%s, %s) of %s: %s"),
31113125
amprocForm->amprocnum,
3112-
format_type_be(amprocForm->amproclefttype),
3113-
format_type_be(amprocForm->amprocrighttype),
3126+
format_type_extended(amprocForm->amproclefttype,
3127+
-1,FORMAT_TYPE_ALLOW_INVALID),
3128+
format_type_extended(amprocForm->amprocrighttype,
3129+
-1,FORMAT_TYPE_ALLOW_INVALID),
31143130
opfam.data,
31153131
format_procedure(amprocForm->amproc));
31163132

0 commit comments

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