| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Joachim Wieland <joe(at)mcknight(dot)de> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: synchronized snapshots |
| Date: | 2011-08-15 07:47:45 |
| Message-ID: | 4E48CF21.90603@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
> 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?
> 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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2011-08-15 07:51:42 | Re: synchronized snapshots |
| Previous Message | Simon Riggs | 2011-08-15 07:40:34 | Re: synchronized snapshots |