Fix dumping of matviews with indirect dependencies on primary keys.

Commit 62215de29 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

diff --git a/src/bin/pg_dump/pg_dump_sort.c b/src/bin/pg_dump/pg_dump_sort.c
index a701532f87a624e82e2475d78e277458edaf3b11..5413ab1e1cdd7a5c3f83901570a92e12568f1818 100644 (file)
--- a/src/bin/pg_dump/pg_dump_sort.c
+++ b/src/bin/pg_dump/pg_dump_sort.c
@@ -19,6 +19,8 @@
 #include "pg_backup_utils.h"
 #include "pg_dump.h"
 
+#include "catalog/pg_class.h"
+
 /* translator: this is a module name */
 static const char *modulename = gettext_noop("sorter");
 
@@ -931,19 +933,26 @@ repairViewRuleMultiLoop(DumpableObject *viewobj,
  *
  * Note that the "next object" is not necessarily the matview itself;
  * it could be the matview's rowtype, for example.  We may come through here
- * several times while removing all the pre-data linkages.
+ * several times while removing all the pre-data linkages.  In particular,
+ * if there are other matviews that depend on the one with the circularity
+ * problem, we'll come through here for each such matview and mark them all
+ * as postponed.  (This works because all MVs have pre-data dependencies
+ * to begin with, so each of them will get visited.)
  */
 static void
-repairMatViewBoundaryMultiLoop(DumpableObject *matviewobj,
-                                                          DumpableObject *boundaryobj,
+repairMatViewBoundaryMultiLoop(DumpableObject *boundaryobj,
                                                           DumpableObject *nextobj)
 {
-       TableInfo  *matviewinfo = (TableInfo *) matviewobj;
-
        /* remove boundary's dependency on object after it in loop */
        removeObjectDependency(boundaryobj, nextobj->dumpId);
-       /* mark matview as postponed into post-data section */
-       matviewinfo->postponed_def = true;
+       /* if that object is a matview, mark it as postponed into post-data */
+       if (nextobj->objType == DO_TABLE)
+       {
+               TableInfo  *nextinfo = (TableInfo *) nextobj;
+
+               if (nextinfo->relkind == RELKIND_MATVIEW)
+                       nextinfo->postponed_def = true;
+       }
 }
 
 /*
@@ -1125,8 +1134,7 @@ repairDependencyLoop(DumpableObject **loop,
                                                DumpableObject *nextobj;
 
                                                nextobj = (j < nLoop - 1) ? loop[j + 1] : loop[0];
-                                               repairMatViewBoundaryMultiLoop(loop[i], loop[j],
-                                                                                                          nextobj);
+                                               repairMatViewBoundaryMultiLoop(loop[j], nextobj);
                                                return;
                                        }
                                }