> On Aug 2, 2020, at 8:59 PM, Peter Geoghegan <p...@bowt.ie> wrote: > > What's the point in not just giving up on the index (though not > necessarily the table or other indexes) at the first sign of trouble, > anyway? It makes sense for the heap structure, but not for indexes. The case that came to mind was an index broken by a glibc update with breaking changes to the collation sort order underlying the index. If the breaking change has already been live in production for quite some time before a DBA notices, they might want to quantify how broken the index has been for the last however many days, not just drop and recreate the index. I'm happy to drop that from the patch, though. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
- Re: new heapcheck contrib module Robert Haas
- Re: new heapcheck contrib module Amul Sul
- Re: new heapcheck contrib module Amul Sul
- Re: new heapcheck contrib module Amul Sul
- Re: new heapcheck contrib module Robert Haas
- Re: new heapcheck contrib module Mark Dilger
- Re: new heapcheck contrib module Peter Geoghegan
- Re: new heapcheck contrib module Mark Dilger
- Re: new heapcheck contrib module Robert Haas
- Re: new heapcheck contrib module Peter Geoghegan
- Re: new heapcheck contrib module Mark Dilger
- Re: new heapcheck contrib module Robert Haas
- Re: new heapcheck contrib module Peter Geoghegan
- Re: new heapcheck contrib module Robert Haas
- Re: new heapcheck contrib module Peter Geoghegan
- Re: new heapcheck contrib module Robert Haas
- Re: new heapcheck contrib module Peter Geoghegan
- Re: new heapcheck contrib module Robert Haas
- Re: new heapcheck contrib module Peter Geoghegan
- Re: new heapcheck contrib module Robert Haas
- Re: new heapcheck contrib module Robert Haas