| From: | "Dann Corbit" <DCorbit(at)connx(dot)com> |
|---|---|
| To: | "Neil Conway" <neilc(at)samurai(dot)com>, "Scott Marlowe" <smarlowe(at)g2switchworks(dot)com> |
| Cc: | "pgsql-general" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Corrupt RTREE index |
| Date: | 2004-12-15 00:43:20 |
| Message-ID: | D425483C2C5C9F49B5B7A41F8944154705572F@postal.corporate.connx.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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(at)samurai(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ben | 2004-12-15 00:55:34 | Which (table) lock mode to use |
| Previous Message | Neil Conway | 2004-12-15 00:39:28 | Re: Corrupt RTREE index |