Assert's vs elog ERROR vs elog FATAL

From: Daniel Wood <dwood(at)salesforce(dot)com>
To: <pgsql-hackers(at)postgresql(dot)org>
Subject: Assert's vs elog ERROR vs elog FATAL
Date: 2013-04-27 03:24:16
Message-ID: 517B44E0.7010100@salesforce.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

These two questions are about the correct coding practice in Postgresql
vs the specifics of xact.c

Is the main difference between:

if (s->blockState != TBLOCK_SUBINPROGESS)
elog(*FATAL*, ...
vs
Assert(s->blockState == TBLOCK_SUBINPROGRESS);

the fact that in both cases:
a) the situation is unexpected, as in no user code can create this;
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 exact value
of blockState, then you need to use the elog(FATAL, ...) way of doing it?

Given the example:
elog(ERROR, "StartTransactionCommand: unexpected state %s", ...
vs
elog(FATAL, "CommitTransactionCommand: unexpected state %s", ...
why is one considered fatal but in the other case handle-able?
I presume the answer is something like: It is subjective and there is
no real rule.
OR: While no user code would ever likely try to handle an elog(ERROR,
...) case, in theory the internal process state is still intact such
that we could safely continue even if there is code that uses the ERROR
situation incorrectly(should be FATAL).

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-04-27 04:26:28 Re: Assert's vs elog ERROR vs elog FATAL
Previous Message Robert Haas 2013-04-27 02:22:29 exactly what is COPY BOTH mode supposed to do in case of an error?