Re: pg_upgrade problem with invalid indexes
От | Bruce Momjian |
---|---|
Тема | Re: pg_upgrade problem with invalid indexes |
Дата | |
Msg-id | 20121211202428.GB5307@momjian.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade problem with invalid indexes (Andres Freund <andres@2ndquadrant.com>) |
Список | pgsql-hackers |
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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: