Assert's vs elog ERROR vs elog FATAL - Mailing list pgsql-hackers

From Daniel Wood
Subject Assert's vs elog ERROR vs elog FATAL
Date
Msg-id 517B44E0.7010100@salesforce.com
Whole thread Raw
Responses Re: Assert's vs elog ERROR vs elog FATAL
List pgsql-hackers
These two questions are about the correct coding practice in Postgresql vs the specifics of xact.c<br /><br /> Is the
maindifference between:<br /><br /><font face="Courier New, Courier, monospace">    if (s->blockState !=
TBLOCK_SUBINPROGESS)<br/>         elog(<b>FATAL</b>, ...<br /> vs<br />     Assert(s->blockState ==
TBLOCK_SUBINPROGRESS);<br/></font><br /> the fact that in both cases:<br />     a) the situation is unexpected, as in
nouser code can create this;<br />     b) however, if you want the check to always be done in production because of
paranoia,or because a failure after this would be harder to figure out, or because you want to log more info, like the
exactvalue of blockState,   then you need to use the elog(FATAL, ...) way of doing it?<br /><br /><br /> Given the
example:<br/><font face="Courier New, Courier, monospace">    elog(ERROR, "StartTransactionCommand: unexpected state
%s",...<br /> vs<br />     elog(FATAL, "CommitTransactionCommand: unexpected state %s", ...</font><br /> why is one
consideredfatal but in the other case handle-able?<br /> I presume the answer is something like:  It is subjective and
thereis no real rule.<br /> OR: While no user code would ever likely try to handle an elog(ERROR, ...) case, in theory
theinternal process state is still intact such that we could safely continue even if there is code that uses the ERROR
situationincorrectly(should be FATAL).<br /> 

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: exactly what is COPY BOTH mode supposed to do in case of an error?
Next
From: Tom Lane
Date:
Subject: Re: Assert's vs elog ERROR vs elog FATAL