| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
| Cc: | Amul Sul <sulamul(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: new heapcheck contrib module |
| Date: | 2020-08-03 03:59:55 |
| Message-ID: | CAH2-WzmS+=4xcjZev-6XAC0opsCm1rTo1AGx1rW5ZVhbrrjS-g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jul 27, 2020 at 10:02 AM Mark Dilger
<mark(dot)dilger(at)enterprisedb(dot)com> wrote:
> I'm indifferent about that change. Done for v13.
Moving on with verification of the same index in the event of B-Tree
index corruption is a categorical mistake. verify_nbtree.c was simply
not designed to work that way.
You were determined to avoid allowing any behavior that can result in
a backend crash in the event of corruption, but this design will
defeat various measures I took to avoid crashing with corrupt data
(e.g. in commit a9ce839a313).
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.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2020-08-03 04:13:06 | Re: new heapcheck contrib module |
| Previous Message | David G. Johnston | 2020-08-03 03:43:53 | Re: Document "59.2. Built-in Operator Classes" have a clerical error? |