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@xxxxxxxxxxx <AYahorau@xxxxxxxxxxx> 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
