On Thu, Dec 16, 2010 at 3:18 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> Hmm. It's seeming to me that what we want to do is something like this: > >> 1. If an error is thrown while DoingCommandRead, it gets upgraded to >> FATAL. I don't think we have much choice about this because, per your >> previous comments, we can't longjmp() here without risking protocol >> breakage, and we certainly can't return from an elog(ERROR) or >> ereport(ERROR). > > Um, if that's the ground rules then we have no advance over the current > situation. > > I guess you misunderstood what I said. What I meant was that we cannot > longjmp *out to the outer level*, ie we cannot take control away from > the input stack. We could however have a TRY block inside the interrupt > handler that catches and handles (queues) any errors occurring during > transaction abort. As long as we eventually return control to openssl > I think it should work.
Is there any real advantage to that? How often do we hit an error trying to abort a transaction? And how will we report the error anyway? I thought the next thing we'd report would be the recovery conflict, not any bizarre can't-abort-the-transaction scenario. > (Hm, but I wonder whether there are any hard > timing constraints in the ssl protocol ... although hopefully xact abort > won't ever take long enough that that's a real problem.) That would be incredibly broken. -- 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
