Hi, On 2023-11-30 16:02:55 -0500, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > Wondering if we should add a ERRCODE_CLUSTER_CORRUPTED for cases like this. > > We > > have ERRCODE_DATA_CORRUPTED and ERRCODE_INDEX_CORRUPTED, which make > > ERRCODE_DATA_CORRUPTED feel a bit too specific in this kind of situation? > > Maybe. We didn't officially define DATA_CORRUPTED as referring to > table data, but given the existence of INDEX_CORRUPTED maybe we > should treat it as that.
I'm on the fence about it. Certainly DATA_CORRUPTED would be more appropriate than INTERNAL_ERROR. > > Hm, this one arguably is not corruption, but we still cannot > > continue. ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE or maybe a new error > > code? > > ... I don't really like turning a whole bunch of error cases into > the same error code without some closer analysis. Other than this instance, they all indicate that the cluster is toast in some way or another. So *_CORRUPTED seems appropriate. And even this instance would be better off as _CORRUPTED than as INTERNAL_ERROR. There's so many of the latter that you can't realistically alert on them occurring. I don't like my idea of ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE much, that's not something you realistically can alert on, and this error certainly is an instance of "you're screwed until you manually intervene". Greetings, Andres Freund