Re: new heapcheck contrib module - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: new heapcheck contrib module
Date
Msg-id ABBF7CB8-0FCA-4611-962A-1BA17E6621BB@enterprisedb.com
Whole thread Raw
In response to Re: new heapcheck contrib module  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers

> On Aug 2, 2020, at 8:59 PM, Peter Geoghegan <pg@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
underlyingthe 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
recreatethe index.  I'm happy to drop that from the patch, though. 

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING
Next
From: Mark Dilger
Date:
Subject: Re: new heapcheck contrib module