Re: [PATCH] V3: Idle in transaction cancellation
От | Tom Lane |
---|---|
Тема | Re: [PATCH] V3: Idle in transaction cancellation |
Дата | |
Msg-id | 11435.1292530738@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCH] V3: Idle in transaction cancellation (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [PATCH] V3: Idle in transaction cancellation
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@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. (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.) regards, tom lane
В списке pgsql-hackers по дате отправления: