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.
>> 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
