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

Commitdc42602

Browse files
committed
Fix dumping of matviews with indirect dependencies on primary keys.
Commit62215de turns out to have been not quite on-the-mark.When we are forced to postpone dumping of a materialized view intothe dump's post-data section (because it depends on a unique indexthat isn't created till that section), we may also have to postponedumping other matviews that depend on said matview. The previous fixdidn't reliably work for such cases: it'd break the dependency loopsproperly, producing a workable object ordering, but it didn'tnecessarily mark all the matviews as "postponed_def". This led toharmless bleating about "archive items not in correct section order",as reported by Tom Cassidy in bug #15602. Less harmlessly,selective-restore options such as --section might misbehave due tothe matview dump objects not being properly labeled.The right way to fix it is to consider that each pre-data dependencywe break amounts to moving the no-longer-dependent object intopost-data, and hence we should mark that object if it's a matview.Back-patch to all supported versions, since the issue's been theresince matviews were introduced.Discussion:https://postgr.es/m/15602-e895445f73dc450b@postgresql.org
1 parente101878 commitdc42602

File tree

1 file changed

+15
-9
lines changed

1 file changed

+15
-9
lines changed

‎src/bin/pg_dump/pg_dump_sort.c

Lines changed: 15 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -844,19 +844,26 @@ repairViewRuleMultiLoop(DumpableObject *viewobj,
844844
*
845845
* Note that the "next object" is not necessarily the matview itself;
846846
* it could be the matview's rowtype, for example. We may come through here
847-
* several times while removing all the pre-data linkages.
847+
* several times while removing all the pre-data linkages. In particular,
848+
* if there are other matviews that depend on the one with the circularity
849+
* problem, we'll come through here for each such matview and mark them all
850+
* as postponed. (This works because all MVs have pre-data dependencies
851+
* to begin with, so each of them will get visited.)
848852
*/
849853
staticvoid
850-
repairMatViewBoundaryMultiLoop(DumpableObject*matviewobj,
851-
DumpableObject*boundaryobj,
854+
repairMatViewBoundaryMultiLoop(DumpableObject*boundaryobj,
852855
DumpableObject*nextobj)
853856
{
854-
TableInfo*matviewinfo= (TableInfo*)matviewobj;
855-
856857
/* remove boundary's dependency on object after it in loop */
857858
removeObjectDependency(boundaryobj,nextobj->dumpId);
858-
/* mark matview as postponed into post-data section */
859-
matviewinfo->postponed_def= true;
859+
/* if that object is a matview, mark it as postponed into post-data */
860+
if (nextobj->objType==DO_TABLE)
861+
{
862+
TableInfo*nextinfo= (TableInfo*)nextobj;
863+
864+
if (nextinfo->relkind==RELKIND_MATVIEW)
865+
nextinfo->postponed_def= true;
866+
}
860867
}
861868

862869
/*
@@ -1038,8 +1045,7 @@ repairDependencyLoop(DumpableObject **loop,
10381045
DumpableObject*nextobj;
10391046

10401047
nextobj= (j<nLoop-1) ?loop[j+1] :loop[0];
1041-
repairMatViewBoundaryMultiLoop(loop[i],loop[j],
1042-
nextobj);
1048+
repairMatViewBoundaryMultiLoop(loop[j],nextobj);
10431049
return;
10441050
}
10451051
}

0 commit comments

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