I think the error codes are documented mainly to be used in a
development environment, like when writing a function that needs to
listen to abnormal behaviour. If you're doing log based monitoring, I
think it's safe to rely on the severity shown in the log file itself.
The multiple possible severity levels for an error code are probably
due to PostgreSQL's modular architecture: maybe an error is relatively
negligible when raised to a client backend process, but a very severe
one when coming from the postmaster.
On 3/21/19, AYahorau@ibagroup.eu <AYahorau@ibagroup.eu> wrote:
> Hello PostgreSQL Community!
>
> I have a question regarding PostgreSQL log messages.
>
> Operating with PostgreSQL and configuring it we need to understand that
> everything goes well. To do this we monitor PostgreSQL log to be sure
> that database works properly indeed.
> We can do it based on error codes described here:
> https://www.postgresql.org/docs/11/errcodes-appendix.html
> and based on these error codes we can see if something is wrong.
>
> But in my view this is not enough. For example a message
> 53400 configuration_limit_exceeded
> can be represented in log with different severities: PANIC/ERROR/WARNING.
> And there are a number of other similar examples.
>
> So, the problem is that it is not easy to understand if the error is
> really critical for system or not.
>
> As far as I know a number of object-relational database management systems
> provide full list of possible messages and relations between them.
> It helps to understand that some critical error is not active any more and
> the database works properly.
>
> Is there such a list for PostgreSQL which contains all the possible events
> and their error codes. Is there a tool which helps to realize that some
> FATAL/PANIC message is not actual now?
>
> Thank You in advance,
> Andrei Yahorau
--
----------
“Life beats down and crushes the soul and art reminds you that you have one.”
- Stella Adler