On Tue, Oct 18, 2011 at 11:27 PM, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
