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

Re: [HACKERS] Deadlock with pg_dump?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Chris Campbell <chris(at)bignerdranch(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] Deadlock with pg_dump?
Date: 2007-03-02 22:05:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > I can create a global variable to control this, but the new elog level
> > seemed cleaner.
> What I don't like about the proposed patch is that it's nonorthogonal.
> I see no reason to suppose that LOG is the only possible elevel for
> which it might be interesting to suppress the STATEMENT: field.


> Perhaps the best thing would be to define an additional ereport
> auxiliary function, say errprintstmt(bool), that could set a flag
> in the current elog stack entry to control suppression of STATEMENT.
> This would mean you couldn't determine the behavior when using elog(),
> but that's not supposed to be used for user-facing messages anyway.

One idea I had was to set the high-bit of elevel to control whether we
want to suppress statement logging, but I think errprintstmt() might be
best.  I don't understand the ereport stack well enough to add this
functionality, though.  What should I look for?

  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: Andrew DunstanDate: 2007-03-02 22:12:39
Subject: Re: proposal: only superuser can change customized_options
Previous:From: Joshua D. DrakeDate: 2007-03-02 21:44:30

pgsql-patches by date

Next:From: Tom LaneDate: 2007-03-02 22:37:33
Subject: Re: [HACKERS] Deadlock with pg_dump?
Previous:From: Jeremy DrakeDate: 2007-03-02 21:47:50
Subject: cosmetic patch to large object regression test

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