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: http://www.postgresql.org/mailpref/pgsql-hackers
