Database Reference
In-Depth Information
"Error" states that are not errors
WARNING
is the highest non-error level. It means that something may be wrong and
needs user/administrator attention. It is a good practice to periodically scan system
logs for warnings. Use this only for unexpected conditions. See the next one for
things happening on regular basis. Warnings go to client and server logs by default.
NOTICE
is for things which are likely of higher interest to users, like information about
creating a primary key index or sequence for serial type (though these stopped to be
NOTICE
in the latest version of PostgreSQL). Like the previous one,
NOTICE
is sent
both to client and server logs by default.
INFO
is for things specifically requested by client, like
VACUUM/ANALYSE VERBOSE
.
It is always sent to the client regardless of
client_min_messages
GUC setting,
but is not written to a server log when using default settings.
LOG
(and
COMMERROR
) are for servers operational messages, and by default are
only written to the server log. The error level
LOG
can also be sent to client if
cli-
ent_min_messages
is set appropriately, but
COMMERROR
never is.
There are
DEBUG1
to
DEBUG5
in increasing order of verbosity. They are specifically
meant for reporting debugging info and are not really useful in most other cases, ex-
cept perhaps for curiosity. Setting higher
DEBUGx
levels is not recommended in pro-
duction servers, as the amount logged or reported can be really huge.
When are messages sent to the client
While most communication from server to client takes place after the command
completes (or even after the transaction is committed in case of
LISTEN
/
NOTIFY
),
everything emitted by
ereport()
is sent to the client immediately, thus the mention
of
off-channel messaging
previously. This makes
ereport()
a useful tool for mon-
itoring long-running commands such as
VACUUM
and also a simple debugging aid to
print out useful debug info.
You can read a much more detailed description of error reporting at
ht-
