Hi Lloyd,

On 2013-06-26 23:43:00 +0000, lal...@fhcrc.org wrote:
> I have found the restore will fail when using pg_restore's -j option, with
> more than one core, on a dump that contains a COMMENT INDEX.

> Run this next section to add the table, index, and index comment to the
> test_db database.

> CREATE TABLE public.tbl_test (
>   pkey TEXT NOT NULL,
>   CONSTRAINT tbl_test_pkey PRIMARY KEY(pkey)
> );

> COMMENT ON INDEX public.tbl_test_pkey
> IS 'Index Comment';

> Once this test database is created, create a backup of the database.
> pg_dump -Fc test_db > test_db.dump

The problem is that pg_dump makes the comment depend on the index
instead of the constraint:

; Selected TOC Entries:
...
170; 1259 69261 TABLE public tbl_test andres
;    depends on: 6
1941; 0 69261 TABLE DATA public tbl_test andres
;     depends on: 170
1833; 2606 69268 CONSTRAINT public tbl_test_pkey andres
;     depends on: 170 170
1950; 0 0 COMMENT public INDEX tbl_test_pkey andres
;     depends on: 1832

There is no object 1832 in the dump since that was ommitted in favor of
the constraint 1833 which internally creates the index. So what we need
to do is to make the comment depend on the constraint instead.

With the attached patch we get:

170; 1259 69261 TABLE public tbl_test andres
;    depends on: 6
1941; 0 69261 TABLE DATA public tbl_test andres
;     depends on: 170
1833; 2606 69268 CONSTRAINT public tbl_test_pkey andres
;     depends on: 170 170
1950; 0 0 COMMENT public INDEX tbl_test_pkey andres
;     depends on: 1833

unsurprisingly after that restore completes.

Greetings,

Andres Freund

-- 
 Andres Freund                     http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index 2ce0cd8..107cabb 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -13493,6 +13493,7 @@ dumpIndex(Archive *fout, IndxInfo *indxinfo)
 	PQExpBuffer q;
 	PQExpBuffer delq;
 	PQExpBuffer labelq;
+	bool is_constraint = indxinfo->indexconstraint != 0;
 
 	if (dataOnly)
 		return;
@@ -13509,7 +13510,7 @@ dumpIndex(Archive *fout, IndxInfo *indxinfo)
 	 * do dump any comment for it.	(This is safe because dependency ordering
 	 * will have ensured the constraint is emitted first.)
 	 */
-	if (indxinfo->indexconstraint == 0)
+	if (!is_constraint)
 	{
 		if (binary_upgrade)
 			binary_upgrade_set_pg_class_oids(fout, q,
@@ -13547,11 +13548,15 @@ dumpIndex(Archive *fout, IndxInfo *indxinfo)
 					 NULL, NULL);
 	}
 
-	/* Dump Index Comments */
+	/*
+	 * Dump Index Comments - depend on the constraint instead of the index if
+	 * present to ensure sensible ordering.
+	 */
 	dumpComment(fout, labelq->data,
 				tbinfo->dobj.namespace->dobj.name,
 				tbinfo->rolname,
-				indxinfo->dobj.catId, 0, indxinfo->dobj.dumpId);
+				indxinfo->dobj.catId, 0,
+		    is_constraint ? indxinfo->indexconstraint : indxinfo->dobj.dumpId);
 
 	destroyPQExpBuffer(q);
 	destroyPQExpBuffer(delq);
-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Reply via email to