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. >> I can certainly see that this would be >> useful but I am not sure if it justifies introducing this >> inconsistency. We would have a BEGIN TRANSACTION command that left the >> session in a different state depending on why it failed... > > I don't understand what inconsistency you're talking about. What else can > cause BEGIN TRANSACTION to fail? Is there currently any failure mode that > doesn't leave the transaction in aborted state? Granted, it might only fail for parse errors so far, but that would include for example sending BEGIN DEFERRABLE to a pre-9.1 server. It wouldn't start a transaction and leave it in an aborted state, but it would just fail. >> I am wondering if pg_export_snapshot() is still the right name, since >> the snapshot is no longer exported to the user. It is exported to a >> file but that's an implementation detail. > > It's still exporting the snapshot to other sessions, that name still seems > appropriate to me. ok. Joachim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers