Re: GiST insert algorithm rewrite
От | Bruce Momjian |
---|---|
Тема | Re: GiST insert algorithm rewrite |
Дата | |
Msg-id | 201012010206.oB126DC08489@momjian.us обсуждение исходный текст |
Ответ на | Re: GiST insert algorithm rewrite (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | pgsql-hackers |
Heikki Linnakangas wrote: > > Does the current code cope with the corruption? > > It's not corruption, but "intended degradation". Yes, the current code > copes with it, that's how GiST survives a crash. However, even with the > current code, VACUUM will nag if it finds any invalid tuples with this > message: > > ereport(NOTICE, > (errmsg("index \"%s\" needs VACUUM FULL or REINDEX to finish crash > recovery", > > That's harmless, in the sense that all scans and inserts work fine, but > scans might need to do more work than if the invalid tuple wasn't there. > > I don't think we need to go out of our way to support such degraded > indexes in 9.1. If you see such notices in your logs, you should REINDEX > anyway, before of after pg_upgrade. Let's just make sure that you get a > reasonable error message in 9.1 if a scan or insert encounters such a tuple. > > There is a section on this in the docs, BTW: > http://www.postgresql.org/docs/9.0/static/gist-recovery.html OK, administrators will be prompted during normal operation --- seems there is nothing extra for pg_upgrade to do here. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: