Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 16e0464

Browse files
committed
Fix dumping of matviews with indirect dependencies on primary keys.
Commit 62215de turns out to have been not quite on-the-mark. When we are forced to postpone dumping of a materialized view into the dump's post-data section (because it depends on a unique index that isn't created till that section), we may also have to postpone dumping other matviews that depend on said matview. The previous fix didn't reliably work for such cases: it'd break the dependency loops properly, producing a workable object ordering, but it didn't necessarily mark all the matviews as "postponed_def". This led to harmless 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 to the matview dump objects not being properly labeled. The right way to fix it is to consider that each pre-data dependency we break amounts to moving the no-longer-dependent object into post-data, and hence we should mark that object if it's a matview. Back-patch to all supported versions, since the issue's been there since matviews were introduced. Discussion: https://postgr.es/m/15602-e895445f73dc450b@postgresql.org
1 parent e7f1d14 commit 16e0464

File tree

1 file changed

+17
-9
lines changed

1 file changed

+17
-9
lines changed

src/bin/pg_dump/pg_dump_sort.c

Lines changed: 17 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -19,6 +19,8 @@
1919
#include "pg_backup_utils.h"
2020
#include "pg_dump.h"
2121

22+
#include "catalog/pg_class.h"
23+
2224
/* translator: this is a module name */
2325
static const char *modulename = gettext_noop("sorter");
2426

@@ -931,19 +933,26 @@ repairViewRuleMultiLoop(DumpableObject *viewobj,
931933
*
932934
* Note that the "next object" is not necessarily the matview itself;
933935
* it could be the matview's rowtype, for example. We may come through here
934-
* several times while removing all the pre-data linkages.
936+
* several times while removing all the pre-data linkages. In particular,
937+
* if there are other matviews that depend on the one with the circularity
938+
* problem, we'll come through here for each such matview and mark them all
939+
* as postponed. (This works because all MVs have pre-data dependencies
940+
* to begin with, so each of them will get visited.)
935941
*/
936942
static void
937-
repairMatViewBoundaryMultiLoop(DumpableObject *matviewobj,
938-
DumpableObject *boundaryobj,
943+
repairMatViewBoundaryMultiLoop(DumpableObject *boundaryobj,
939944
DumpableObject *nextobj)
940945
{
941-
TableInfo *matviewinfo = (TableInfo *) matviewobj;
942-
943946
/* remove boundary's dependency on object after it in loop */
944947
removeObjectDependency(boundaryobj, nextobj->dumpId);
945-
/* mark matview as postponed into post-data section */
946-
matviewinfo->postponed_def = true;
948+
/* if that object is a matview, mark it as postponed into post-data */
949+
if (nextobj->objType == DO_TABLE)
950+
{
951+
TableInfo *nextinfo = (TableInfo *) nextobj;
952+
953+
if (nextinfo->relkind == RELKIND_MATVIEW)
954+
nextinfo->postponed_def = true;
955+
}
947956
}
948957

949958
/*
@@ -1125,8 +1134,7 @@ repairDependencyLoop(DumpableObject **loop,
11251134
DumpableObject *nextobj;
11261135

11271136
nextobj = (j < nLoop - 1) ? loop[j + 1] : loop[0];
1128-
repairMatViewBoundaryMultiLoop(loop[i], loop[j],
1129-
nextobj);
1137+
repairMatViewBoundaryMultiLoop(loop[j], nextobj);
11301138
return;
11311139
}
11321140
}

0 commit comments

Comments
 (0)