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

Commit318fd99

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 parent3c017a5 commit318fd99

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
@@ -37,6 +37,7 @@
3737
#include"catalog/pg_shdescription.h"
3838
#include"catalog/pg_shseclabel.h"
3939
#include"catalog/pg_tablespace.h"
40+
#include"catalog/pg_type.h"
4041
#include"catalog/toasting.h"
4142
#include"miscadmin.h"
4243
#include"storage/fd.h"
@@ -336,6 +337,14 @@ GetNewOidWithIndex(Relation relation, Oid indexId, AttrNumber oidcolumn)
336337
ScanKeyDatakey;
337338
boolcollides;
338339

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

341350
/* Generate new OIDs until we find one not in the table */
@@ -387,6 +396,13 @@ GetNewRelFileNode(Oid reltablespace, Relation pg_class, char relpersistence)
387396
boolcollides;
388397
BackendIdbackend;
389398

399+
/*
400+
* If we ever get here during pg_upgrade, there's something wrong; all
401+
* relfilenode assignments during a binary-upgrade run should be
402+
* determined by commands in the dump script.
403+
*/
404+
Assert(!IsBinaryUpgrade);
405+
390406
switch (relpersistence)
391407
{
392408
caseRELPERSISTENCE_TEMP:

0 commit comments

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