On Tue, Mar 26, 2013 at 09:43:54PM +0000, Tom Lane wrote: > 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.
This commit affects pg_upgrade. You might remember we had to patch pg_upgrade to prevent it from migrating clusters with invalid indexes in December, 2012: http://momjian.us/main/blogs/pgblog/2012.html#December_14_2012 This was released on February 7, 2013 in 9.2.3 and other back branches: http://www.postgresql.org/docs/9.2/static/release-9-2-3.html This git commit means that pg_upgrade can again migrate systems with invalid indexes as pg_upgrade can just skip migrating them because pg_dump will dump the SQL commands to create them --- previously pg_upgrade threw an error. Should I just patch pg_upgrade to remove the "indisvalid", skip "indisvalid" indexes, and backpatch it? Users should be using the version of pg_upgrade to match new pg_dump. Is there any case where they don't match? Do I still need to check for "indisready"? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers