Database Reference
In-Depth Information
Error reporting from C functions
One thing which went unexplained in the previous sample was the error reporting part:
if (ARR_NDIM(input_array) > 1)
ereport(ERROR,
(errcode(ERRCODE_ARRAY_SUBSCRIPT_ERROR),
errmsg ("use only
one-dimensional arrays!")));
All error reporting and other off-channel messaging in PostgreSQL is done using the
ereport(<errorlevel>, rest) macro. The main purpose of which is to make
error reporting look like a function call.
The only parameter which is processed directly by ereport() is the first argument
error level, or perhaps more exactly severity level or log level. All the other parameters
are actually function calls which independently generate and store additional error in-
formation in the system to be written to logs and/or be sent to client. Being placed in
the argument list of the ereport() makes sure that these other functions are called
before the actual error is reported. This is important because in the case of an er-
ror level being ERROR , FATAL , or PANIC the system cleans up all current transac-
tion state and anything after the ereport() call will never get a chance to run. Error
states the end the transaction.
In case of ERROR the system is returned to a clean state and it will be ready to accept
new commands.
Error level FATAL will clean up the backend and exit the current session.
PANIC is the most destructive one and it will not only end the current connection, but
will also cause all other connections to be terminated. PANIC means that shared state
(shared memory) is potentially corrupted and it is not safe to continue. It is used auto-
matically for things like core dumps or other "hard" crashes.
Search WWH ::




Custom Search