Re: new heapcheck contrib module

On Tue, Feb 23, 2021 at 12:38 PM Mark Dilger
<mark(dot)dilger(at)enterprisedb(dot)com> wrote:
> This is changed in v40 as you propose to exit on FATAL and PANIC level errors and on error to send a query. On lesser errors (which includes all corruption reports about btrees and some heap corruption related errors), the slot's connection is still useable, I think. Are there cases where the error is lower than FATAL and yet the connection needs to be reestablished? It does not seem so from the testing I have done, but perhaps I'm not thinking of the right sort of non-fatal error?

I think you should assume that if you get an ERROR you can - and
should - continue to use the connection, but still exit non-zero at
the end. Perhaps one can contrive some scenario where that's not the
case, but if the server does the equivalent of "ERROR: session
permanently borked" we should really change those to FATAL; I think
you can discount that possibility.

> In v40, exit(1) means the program encountered fatal errors leading it to stop, and exit(2) means that a non-fatal error and/or corruption reports occurred somewhere during the processing. Otherwise, exit(0) means your database was successfully checked and is healthy.

wfm.

--
Robert Haas
EDB: http://www.enterprisedb.com