Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h6zHn-0004p9-5o for pgsql-admin@arkaria.postgresql.org; Thu, 21 Mar 2019 15:07:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h6zHl-0005wW-OD for pgsql-admin@arkaria.postgresql.org; Thu, 21 Mar 2019 15:07:13 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h6zHl-0005uF-5w for pgsql-admin@lists.postgresql.org; Thu, 21 Mar 2019 15:07:13 +0000 Received: from mail-ot1-x341.google.com ([2607:f8b0:4864:20::341]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h6zHg-0000Gl-Kq for pgsql-admin@lists.postgresql.org; Thu, 21 Mar 2019 15:07:12 +0000 Received: by mail-ot1-x341.google.com with SMTP id f10so5691755otb.6 for ; Thu, 21 Mar 2019 08:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=AxGbh0+vdkV8edw7jMBKa3Mm1F0UWwaxtjgExM1S+Nw=; b=dq2VzUN/zTQ6JM+xfGXlxTKR7clYUivxuyswmVrkTQuPgFJrRCM9p+bbrKvDPEASZt xoQQc4tc/BFnhM+TBp09G+KpSZiLdH2aDsRWGMEveil2DVfUriImblOyfiNZ+sO4anvP 2f4ajzI7KZpnDNLFA8nOg/XaV7E9zywm/9xMw+9jeWNMXsjRrZArIdi4XqjR48spYPh1 FyrL8/rBsLo253wFxD/dxpRirQwdt2gswt8s6DyG50sJCmR0AuBqObVcuTSpeAAWsSro yT/x9X+RwnVM+8Wk6JF5t7Gonjb9YOeSMWwv6iRbUSuiLiTWxDmPocVKWZFnNGJyfsXy MVEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=AxGbh0+vdkV8edw7jMBKa3Mm1F0UWwaxtjgExM1S+Nw=; b=rK37ifWoIK60ZVXRmX8OmnZ0sj08bO/O5nSSt5xSQaCoZd9+7DBGU8oLRNlDl0jqsX 6zb4Xl2NdOvkYhTC1jTTLNSKWjrwle6uF8EbS+YX/h6zKBDPM74iy3P+HQUsacTYYClG Iz/z5DEXYuEAArUMtX8gwuPo+jMbWeZeqUhvPxOwfnRwYu0YtoA83u4haU7RqNvF9E70 Cou88tbJdjlvLYD8F5Ix4urqiaGjDiJJAkNK44UggzZk83D3qzeBQOd8FUPJ3OtmEw9A CR/OK5o5vl7LJxZ3StlsY9If8jaRarZj/kft5R9srVVBlrNsYEFUtbi84W8FWV8IJSz7 RFkA== X-Gm-Message-State: APjAAAVGOcLwPqbdgOjouyKO+m+aJW2KSz1SfSBK2Gt9lZo/QfL2kEam uB3osoBHyMcBB4QiV5j2M4OJNgcLXs0= X-Google-Smtp-Source: APXvYqwVVOXizTG1e0Paw21WTdXMIrxspbDhIWzL65sFid7eGOiCv08TGMSNKHgRCgKluAAfcyTLYg== X-Received: by 2002:a9d:7ac2:: with SMTP id m2mr3036628otn.4.1553180827466; Thu, 21 Mar 2019 08:07:07 -0700 (PDT) Received: from [192.168.1.10] (ip70-171-116-89.no.no.cox.net. [70.171.116.89]) by smtp.googlemail.com with ESMTPSA id j66sm2149982otj.31.2019.03.21.08.07.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Mar 2019 08:07:06 -0700 (PDT) Subject: Re: A question regarding postgresql log messages, To: pgsql-admin@lists.postgresql.org References: From: Ron Message-ID: <4a4ba715-ad82-6767-a5f9-225c985deb23@gmail.com> Date: Thu, 21 Mar 2019 10:07:05 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C7A7CA7AF7FC820FE4768BE4" Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This is a multi-part message in MIME format. --------------C7A7CA7AF7FC820FE4768BE4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit If you see many of these errors, it could very well be an indication of a hack attempt. On 3/21/19 9:03 AM, AYahorau@ibagroup.eu wrote: > Thank you for your response. > > I agree with you concerning  the significance of messages. > I also consider that there is no need to pay attention to such type of errors: > *28P01 FATAL :  password authentication failed for user "user1"* > despite its FATAL severity. > > But how can I distinguish between really significant errors and the errors > which can be ignored? > Is there some kind of indicator  for it? > > Best regards, > Andrei Yahorau > > > > From: nunks > To: AYahorau@ibagroup.eu, > Cc: pgsql-admin@postgresql.org, MikalaiKeida@ibagroup.eu > 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@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 > -- Angular momentum makes the world go 'round. --------------C7A7CA7AF7FC820FE4768BE4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit If you see many of these errors, it could very well be an indication of a hack attempt.

On 3/21/19 9:03 AM, AYahorau@ibagroup.eu wrote:
Thank you for your response.

I agree with you concerning  the significance of messages.
I also consider that there is no need to pay attention to such type of errors:
28P01 FATAL :  password authentication failed for user "user1"
despite its FATAL severity.

But how can I distinguish between really significant errors and the errors which can be ignored?
Is there some kind of indicator  for it?

Best regards,
Andrei Yahorau



From:        nunks <nunks.lol@gmail.com>
To:        AYahorau@ibagroup.eu,
Cc:        pgsql-admin@postgresql.org, MikalaiKeida@ibagroup.eu
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@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

--
Angular momentum makes the world go 'round.
--------------C7A7CA7AF7FC820FE4768BE4--