On Tue, Dec 11, 2012 at 09:19:34PM +0100, Andres Freund wrote: > > > > Only 9.2 :(. Before that there was no DROP INDEX CONCURRENTLY and in 9.3 > > > > there's an actual indislive field and indisready is always set to false > > > > there if indislive is false. > > > > > > > > But I see no problem using !indisvalid || !indisready as the condition > > > > in all (supported) versions. > > > > > > OK, updated patch attached. > > > > Patch applied back to 9.0. > > > > Now that it is applied, I need to publicize this. How do I do that? > > Josh mentioned my blog. > > Not really sure why this needs to be so much more prominent than other > fixes?
Because it creates an post-upgrade system that might return wong results with no warning. > > What would cause these invalid indexes? Just CREATE INDEX CONCURRENTLY > > failures? What types of failures would users have if these invalid > > indexes had been upgraded by pg_upgrade? > > Afaics it could be anything from wrong responses to queries to crashes > although the former seems to be more likely. > > > Can they test their indexes in any way? I assume they can't run > > queries on the old cluster to check. > > I don't see how. That's what I thought. This is not good. :-( -- 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 (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
