On 01.12.2010 04:10, Robert Haas wrote:
On Tue, Nov 30, 2010 at 10:26 AM, Heikki Linnakangas
<heikki.linnakan...@enterprisedb.com> 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.
I just don't want to take a risk of giving people unexpected wrong
answers. It's not clear to me whether that's a risk here or not.
You'll get an error if a scan encounters an invalid tuple.
In the patch I posted, I just ripped out everything related to invalid
tuples altogether. But we should add a check and ereport for that before
commit.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
