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

Commit7332c3c

Browse files
committed
Assert that we don't invent relfilenodes or type OIDs in binary upgrade.
During pg_upgrade's restore run, all relfilenode choices should beoverridden by commands in the dump script. If we ever find ourselveschoosing a relfilenode in the ordinary way, someone blew it. Likewise forpg_type OIDs. Since pg_upgrade might well succeed anyway, if there happensnot to be a conflict during the regression test run, we need assertionshere to keep us on the straight and narrow.We might someday be able to remove the assertion in GetNewRelFileNode,if pg_upgrade is rewritten to remove its assumption that old and newrelfilenodes always match. But it's hard to see how to get rid of thepg_type OID constraint, since those OIDs are embedded in user tablesin some cases.Back-patch as far as 9.5, because of the risk of back-patches breakingsomething here even if it works in HEAD. I'd prefer to go back further,but 9.4 fails both assertions due to get_rel_infos()'s use of a temporarytable. We can't use the later-branch solution of a CTE for compatibilityreasons (cf commit5d16332), and it doesn't seem worth inventing someother way to do the query. (I did check, by dint of changing the Assertsto elog(WARNING), that there are no other cases of unwanted OID assignmentsduring 9.4's regression test run.)Discussion:https://postgr.es/m/19785.1497215827@sss.pgh.pa.us
1 parenta475e46 commit7332c3c

File tree

1 file changed

+16
-0
lines changed

1 file changed

+16
-0
lines changed

‎src/backend/catalog/catalog.c

Lines changed: 16 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -38,6 +38,7 @@
3838
#include"catalog/pg_shseclabel.h"
3939
#include"catalog/pg_subscription.h"
4040
#include"catalog/pg_tablespace.h"
41+
#include"catalog/pg_type.h"
4142
#include"catalog/toasting.h"
4243
#include"miscadmin.h"
4344
#include"storage/fd.h"
@@ -340,6 +341,14 @@ GetNewOidWithIndex(Relation relation, Oid indexId, AttrNumber oidcolumn)
340341
ScanKeyDatakey;
341342
boolcollides;
342343

344+
/*
345+
* We should never be asked to generate a new pg_type OID during
346+
* pg_upgrade; doing so would risk collisions with the OIDs it wants to
347+
* assign. Hitting this assert means there's some path where we failed to
348+
* ensure that a type OID is determined by commands in the dump script.
349+
*/
350+
Assert(!IsBinaryUpgrade||RelationGetRelid(relation)!=TypeRelationId);
351+
343352
InitDirtySnapshot(SnapshotDirty);
344353

345354
/* Generate new OIDs until we find one not in the table */
@@ -391,6 +400,13 @@ GetNewRelFileNode(Oid reltablespace, Relation pg_class, char relpersistence)
391400
boolcollides;
392401
BackendIdbackend;
393402

403+
/*
404+
* If we ever get here during pg_upgrade, there's something wrong; all
405+
* relfilenode assignments during a binary-upgrade run should be
406+
* determined by commands in the dump script.
407+
*/
408+
Assert(!IsBinaryUpgrade);
409+
394410
switch (relpersistence)
395411
{
396412
caseRELPERSISTENCE_TEMP:

0 commit comments

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