Re: termination of backend waiting for sync rep generates a junk log message

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: termination of backend waiting for sync rep generates a junk log message
Date: 2011-10-19 04:06:26
Message-ID: CA+TgmoYPyKMx-3KJSnG5XaNPpi-SuFYs4=g=2dsVLFHoiJrrNg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 18, 2011 at 11:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> One thing worth asking is why we're willing to violate half a dozen
> different coding rules if we see ProcDiePending, yet we're perfectly
> happy to rely on the client understanding a WARNING for the
> QueryCancelPending case.  Another is whether this whole function isn't
> complete BS in the first place, since it appears to be coded on the
> obviously-false assumption that nothing it calls can throw elog(ERROR)
> --- and of course, if any of those functions do throw ERROR, all the
> argumentation here goes out the window.

Well, there is a general problem that anything which throws an ERROR
too late in the commit path is Evil; and sync rep makes that worse to
the extent that it adds more stuff late in the commit path, but it
didn't invent the problem. What it did do is add stuff late in the
commit path that can block for a potentially unbounded period of time,
and I don't see that there are any solutions to that problem that
aren't somewhat grotty.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-10-19 04:20:29 Re: Silent failure with invalid hba_file setting
Previous Message Peter Eisentraut 2011-10-19 03:50:43 Re: Silent failure with invalid hba_file setting