Re: synchronized snapshots - Mailing list pgsql-hackers

From Joachim Wieland
Subject Re: synchronized snapshots
Date
Msg-id CACw0+137w20mdS-vgsJ59FnvNKz-fvfdvda00htH-TDCmfg8-A@mail.gmail.com
Whole thread Raw
In response to Re: synchronized snapshots  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: synchronized snapshots
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: walprotocol.h vs frontends
Next
From: Robert Haas
Date:
Subject: Re: pg_stat_replication vs StandbyReplyMessage