Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TmeTz-0004vW-0c for pgsql-admin@arkaria.postgresql.org; Sun, 23 Dec 2012 05:52:19 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1TmeTx-0005KV-Qx for pgsql-admin@arkaria.postgresql.org; Sun, 23 Dec 2012 05:52:17 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TmeTx-0005Iy-0t for pgsql-admin@postgresql.org; Sun, 23 Dec 2012 05:52:17 +0000 Received: from dub0-omc1-s16.dub0.hotmail.com ([157.55.0.215]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TmeTu-0007YE-KG for pgsql-admin@postgresql.org; Sun, 23 Dec 2012 05:52:16 +0000 Received: from DUB116-W20 ([157.55.0.237]) by dub0-omc1-s16.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 22 Dec 2012 21:52:13 -0800 X-EIP: [FurSF+zJdAreMNAA7umh04+LO84pHJ1u] X-Originating-Email: [kong_mansatiansin@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_bab3a38e-74fc-4a3e-86cc-13bea05c1169_" From: Kong Man To: Subject: log_min_messages=debug5, despite an explicit setting to warning on postgresql.conf Date: Sat, 22 Dec 2012 21:52:13 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 23 Dec 2012 05:52:13.0501 (UTC) FILETIME=[A80096D0:01CDE0D1] X-Pg-Spam-Score: -0.0 (/) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org --_bab3a38e-74fc-4a3e-86cc-13bea05c1169_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We ran into a production issue during our maintenance window when I switche= d over LifeKeeper/PostgreSQL nodes from one to another. We noticed that th= e database was 1000 times slower than it usually is=2C then realized that t= he log_min_messages setting was set to 'debug5' for no reason. Facts: The postgresql.conf file has always been using the default value=2C which i= s 'warning'.An attempt to explicitly set log_min_messages=3Dwarning and rel= oad could not override the setting of 'debug5'.The heavy debug5 logging on = our production system drastically slowed down our database=2C and eventuall= y filled up the root file system (due to the huge /var/log/postgresql)The L= ifeKeeper failover has been done in a recent past with the same unmodified = postgresql.log file without such an excessive logging behavior.Changing log= _destination from syslog to stderr appeared to have done the trick=2C after= hours of troubleshooting. The log_min_messages value took the explicit se= tting from postgresql.log ('warning') and restored our database performance= . I could not find any relevant issue reported and want to see if anyone has = a clue about this issue. Thank you=2C -Kong = --_bab3a38e-74fc-4a3e-86cc-13bea05c1169_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
We ran into a production issue during our maintenance window when I switche= d over LifeKeeper/PostgreSQL nodes from one to another. =3B We noticed = that the database was 1000 times slower than it usually is=2C then realized= that the log_min_messages setting was set to 'debug5' for no reason.
Facts:
  • The postgresql.conf file has always been using the defa= ult value=2C which is 'warning'.
  • An attempt to explicitly set log_m= in_messages=3Dwarning and reload could not override the setting of 'debug5'= .
  • The heavy debug5 logging on our production system drastically slo= wed down our database=2C and eventually filled up the root file system (due= to the huge /var/log/postgresql)
  • The LifeKeeper failover has been = done in a recent past with the same unmodified postgresql.log file without = such an excessive logging behavior.
  • Changing log_destination from s= yslog to stderr appeared to have done the trick=2C after hours of troublesh= ooting. =3B The log_min_messages value took the explicit setting from p= ostgresql.log ('warning') and restored our database performance.
<= br>I could not find any relevant issue reported and want to see if anyone h= as a clue about this issue.

Thank you=2C
-Kong
= --_bab3a38e-74fc-4a3e-86cc-13bea05c1169_--