Tom Lane <tgl@sss.pgh.pa.us> writes:
> What it comes down to is that a lot of code in the backend assumes that
> transaction abort can be relied on to do any post-elog cleanup needed,
> such as releasing locks or reclaiming leaked memory. I don't think we
> can afford to give up that assumption; the costs in code complexity and
> instability would be horrific. What we have to do is generalize the
> abort cleanup code so it can handle partial rollbacks as well as
> complete ones. Thus "nested transactions" is really a shorthand for
> this problem of post-error cleanup.
So you picture the backend automatically introducing a mini-nested-transaction
for every request and automatically rolling that back on any error. So the
application or user wouldn't have to do anything to continue processing
ignoring the error?
--
greg
