Joachim Wieland <j...@mcknight.de> writes:
> On Thu, Jan 7, 2010 at 7:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> As far as I can think at the moment, the best you can do is throw the
>> elog(ERROR), and if control gets out to the error recovery block in
>> PostgresMain, you can force a transaction abort there. In other words,
>> pretty much the same logic that was there before; the only addition that
>> I think is safe is to allow this to happen while DoingCommandRead, so
>> that you can cancel an idle transaction.
> Sorry, but to be clear about this, what do you mean with "allow this
> to happen"? You mean that while DoingCommandRead it should be safe to
> abort the transaction even from the signal handler or only from the
> sigjmp catcher?
In the previous coding, nothing at all happened if DoingCommandRead.
What I am suggesting (and what should be actually safe after my fixes
a couple hours ago) is that it is okay to allow a query-cancel error
to be thrown while in DoingCommandRead state. (Of course there are
still nasty implications for the FE/BE protocol, but at least you won't
crash the backend by doing so.) What is not, and never will be, safe
is to do any sort of transaction-aborting work inside ProcessInterrupts.
You can either throw a regular elog(ERROR) and hope that subsequent
transaction abort will do what you want, or throw elog(FATAL) and let
the cleanup happen during proc_exit. The reason the second form is safe
is that control won't ever return to whatever it was you interrupted,
and so any expectations that such code might have about being able to
recover from the error and continue its processing won't matter.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
