On 2013-03-29 16:57:06 -0400, Bruce Momjian wrote: > On Thu, Mar 28, 2013 at 05:27:28PM -0400, Tom Lane wrote: > > Bruce Momjian <br...@momjian.us> writes: > > > 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"? > > > > Yeah, if you can just ignore !indisvalid indexes that should work fine. > > I see no need to look at indisready if you're doing that. > > Attached is a patch that implements the suggested pg_upgrade changes of > not copying invalid indexes now that pg_dump doesn't dump them. This > should be backpatched back to 8.4 to match pg_dump. It might require > release note updates; not sure. Previously pg_upgrade threw an error > if invalid indexes exist, but only since February, when we released the > pg_upgrade fix to do this. You can see the majority of this patch is > removing that check.
> + "RIGHT OUTER JOIN pg_catalog.pg_index i " > + " ON (c.oid = i.indexrelid) " > "WHERE relkind IN ('r', 'm', 'i'%s) AND " > + /* pg_dump only dumps valid indexes; testing > indisready is > + * necessary in 9.2, and harmless in earlier/later > versions. */ > + " i.indisvalid IS DISTINCT FROM false AND " > + " i.indisready IS DISTINCT FROM false AND " > /* exclude possible orphaned temp tables */ > " ((n.nspname !~ '^pg_temp_' AND " > " n.nspname !~ '^pg_toast_temp_' AND " Those columns cannot be NULL, so using IS DISTINCT FROM seems a bit clumsy. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers