Tom Lane <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
