From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Transaction aborts on syntax error. |
Date: | 2004-02-09 14:33:11 |
Message-ID: | 87hdy0nx08.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Keith Bottner | 2004-02-09 14:53:01 | Re: RFC: Very large scale postgres support |
Previous Message | Jan Wieck | 2004-02-09 14:33:09 | Re: [HACKERS] Sync vs. fsync during checkpoint |