Re: Corrupt RTREE index - Mailing list pgsql-general

From Dann Corbit
Subject Re: Corrupt RTREE index
Date
Msg-id D425483C2C5C9F49B5B7A41F8944154705572F@postal.corporate.connx.com
Whole thread Raw
In response to Corrupt RTREE index  (Greg Stark <gsstark@mit.edu>)
Responses Re: Corrupt RTREE index  (Scott Marlowe <smarlowe@g2switchworks.com>)
List pgsql-general
Would it be possible to rebuild all non-btree indexes when a recovery
takes place?

Another thing that seems it might be nice is to check the non-btree
indexes during analyze (if that is possible and not too expensive).

-----Original Message-----
From: Neil Conway [mailto:neilc@samurai.com]
Sent: Tuesday, December 14, 2004 4:39 PM
To: Scott Marlowe
Cc: Dann Corbit; pgsql-general
Subject: Re: [GENERAL] Corrupt RTREE index

On Tue, 2004-12-14 at 14:12 -0600, Scott Marlowe wrote:
> IS this same issue true for hash or GiST indexes?

Yes, it is: currently, only btree indexes are WAL safe.

(I spent some time recently looking into adding page-level concurrency
and WAL to GiST, but I haven't had a chance to finish that work -- it is
quite a big job...)

-Neil



pgsql-general by date:

Previous
From: Neil Conway
Date:
Subject: Re: Corrupt RTREE index
Next
From: Ben
Date:
Subject: Which (table) lock mode to use