On Aug 15, 2011, at 6:23 AM, Joachim Wieland wrote:
> On Mon, Aug 15, 2011 at 3:47 AM, Heikki Linnakangas
> <heikki.linnakan...@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 with one 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 that something was wrong. A missing file 
is definitely not a syntax error, so we can't really depend on user testing to 
ensure this is handled correctly. IMO, that makes it critical that that error 
puts us in an aborted transaction.
Jim C. Nasby, Database Architect                   j...@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to