> Maybe you can use an informative log_line_prefix
configuration, like
> the proposed pg_badger one:
> '%t [%p]: [%l-1] user=%u,db=%d,app=%a,client=%h
'
> This should give you more information about the
real importance of the
> error message to your use case. A FATAL error from user "postgres"
or
> "[unknown]" can be potentially more problematic than an
error from
> "user1". Also, postmaster messages won't have any of these
variables
> set:
> 2019-03-21 12:21:32 -03 [1714]: [17-1] user=,db=,app=,client=
LOG:
> checkpoint starting: time
Thank you so much for this suggestion.
I have another question. As far as I know there is a number of tools which
collect some statistic concerning some Postgres issues
(connections, disconnections, queries,
most frequent events etc.) based on Postgres Log and so on and so forth.
Do you know is there such a tool or
a set of some actions which can give a precise final answer whether db
server /db is operable or not?
So in this case does not matter how this answer can be got (postgres log
parsing or some sql queries).
Thank you in advance,
Andrei Yahorau
From:
nunks <nunks.lol@xxxxxxxxx>
To:
AYahorau@xxxxxxxxxxx,
Cc:
pgsql-admin@xxxxxxxxxxxxxx,
MikalaiKeida@xxxxxxxxxxx
Date:
21/03/2019 16:31
Subject:
Re: A question
regarding postgresql log messages,
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
