diff options
| author | Tom Lane | 2013-03-26 21:43:30 +0000 |
|---|---|---|
| committer | Tom Lane | 2013-03-26 21:43:30 +0000 |
| commit | f4428cc21ddab3761a090a4f4d82bd6aa6e5d82f (patch) | |
| tree | a77fb5b0f58cba7582731c29be6c39e3b8e3fe67 | |
| parent | 40ce24c591c1f1a4707078da04d09797898c4e2c (diff) | |
Ignore invalid indexes in pg_dump.
Dumping invalid indexes can cause problems at restore time, for example
if the reason the index creation failed was because it tried to enforce
a uniqueness condition not satisfied by the table's data. Also, if the
index creation is in fact still in progress, it seems reasonable to
consider it to be an uncommitted DDL change, which pg_dump wouldn't be
expected to dump anyway.
Back-patch to all active versions, and teach them to ignore invalid
indexes in servers back to 8.2, where the concept was introduced.
Michael Paquier
| -rw-r--r-- | src/bin/pg_dump/pg_dump.c | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c index 8f9c4301912..390ce490c93 100644 --- a/src/bin/pg_dump/pg_dump.c +++ b/src/bin/pg_dump/pg_dump.c @@ -4028,6 +4028,7 @@ getIndexes(TableInfo tblinfo[], int numTables) "i.indexrelid = c.conindid AND " "c.contype IN ('p','u','x')) " "WHERE i.indrelid = '%u'::pg_catalog.oid " + "AND i.indisvalid " "ORDER BY indexname", tbinfo->dobj.catId.oid); } @@ -4056,6 +4057,7 @@ getIndexes(TableInfo tblinfo[], int numTables) "ON (d.refclassid = c.tableoid " "AND d.refobjid = c.oid) " "WHERE i.indrelid = '%u'::pg_catalog.oid " + "AND i.indisvalid " "ORDER BY indexname", tbinfo->dobj.catId.oid); } |