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
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 |