Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Deadlock with pg_dump?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Chris Campbell <chris(at)bignerdranch(dot)com>, pgsql-patches(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Deadlock with pg_dump?
Date: 2007-02-26 20:10:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Simon Riggs wrote:
> On Mon, 2007-02-26 at 13:34 -0500, Bruce Momjian wrote:
> > I am a little concerned about a log_* setting that is INFO. I understand
> > why you used INFO (for log_min_error_messages), but INFO is inconsistent
> > with the log* prefix, and by default INFO doesn't appear in the log
> > file.
> Yeh, LOG would be most appropriate, but thats not possible.
> log_min_messages allows only DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1,
> INFO, NOTICE and WARNING for non-error states.
> Possibly DEBUG1?

This highlights a problem we have often had with LOG output where we
also want the query.

I think there are two possible approaches.  First, we could add a new
bitmap value like LOG_STATEMENT to ereport when we want the statement
with the log line:

	ereport (LOG | LOG_STATEMENT, ...)

(or a new LOG_WITH_STATEMENT log level) and a new GUC like
"log_include_statement" that would control the output of statements for
certain GUC parameters, and we document with GUC values it controls.

A simpler idea would be to unconditionally include the query in the
errdetail() of the actual LOG ereport.

This is not the first GUC that has needed this.  We had this issue with
"log_temp_files", which we just added, and the only suggested solution
was to use log_statement = 'all'.  Either of these ideas above would be
useful for this as well.

  Bruce Momjian  <bruce(at)momjian(dot)us>

  + If your life is a hard drive, Christ can be your backup. +

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2007-02-26 20:13:53
Subject: Re: Simple Column reordering
Previous:From: Simon RiggsDate: 2007-02-26 20:05:07
Subject: Re: [HACKERS] Deadlock with pg_dump?

pgsql-patches by date

Next:From: Tom LaneDate: 2007-02-26 20:15:43
Subject: Re: [HACKERS] Deadlock with pg_dump?
Previous:From: Simon RiggsDate: 2007-02-26 20:05:07
Subject: Re: [HACKERS] Deadlock with pg_dump?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group