On Aug 15, 2011, at 6:23 AM, Joachim Wieland wrote:
> On Mon, Aug 15, 2011 at 3:47 AM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>> On 15.08.2011 04:31, Joachim Wieland wrote:
>>>
>>> The one thing that it does not implement is leaving the transaction in
>>> an aborted state if the BEGIN TRANSACTION command failed for an
>>> invalid snapshot identifier.
>>
>> So what if the snapshot is invalid, the SNAPSHOT clause silently ignored?
>> That sounds really bad.
>
> No, the command would fail, but since it fails, it doesn't change the
> transaction state.
>
> What was proposed originally was to start a transaction but throw an
> error that leaves the transaction in the aborted state. But then the
> command had some effect because it started a transaction block, even
> though it failed.
It certainly seems safer to me to set the transaction to an aborted state; you were expecting a set of commands to run
withone snapshot, but if we don't abort the transaction they'll end up running anyway and doing so with the *wrong*
snapshot.That could certainly lead to data corruption.
I suspect that all the other cases of BEGIN failing would be syntax errors, so you would immediately know in testing
thatsomething was wrong. A missing file is definitely not a syntax error, so we can't really depend on user testing to
ensurethis is handled correctly. IMO, that makes it critical that that error puts us in an aborted transaction.
--
Jim C. Nasby, Database Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net