synchronized snapshots

From: Joachim Wieland <joe(at)mcknight(dot)de>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: synchronized snapshots
Date: 2011-08-15 01:31:20
Message-ID: CACw0+12Bvv=dshD84AEPoBkzTG=K1Z-7vQnbXuhzxdYOOo+==A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

This is a patch to implement synchronized snapshots. It is based on
Alvaro's specifications in:

http://archives.postgresql.org/pgsql-hackers/2011-02/msg02074.php

In short, this is how it works:

SELECT pg_export_snapshot();
pg_export_snapshot
--------------------
000003A1-1
(1 row)

(and then in a different session)

BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ (SNAPSHOT = '000003A1-1');

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

Also I was unsure if we really need to do further checking beyond the
existence of the file, why exactly is this necessary?

The patch is adding an extra "stemplate" parameter to the GetSnapshot
functions, the primary reason for this is to make it work with SSI,
which gets a snapshot and then does stuff with it. The alternative
would have been splitting up the SSI function so that we can smuggle
in our own snapshot but that didn't seem to be less ugly. The way it
works now is that the lowest function checks if a template is being
passed from higher up and if so, it doesn't get a fresh snapshot but
returns just a copy of the template.

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.

Joachim

Attachment Content-Type Size
syncSnapshots.1.diff text/x-patch 45.2 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-08-15 03:27:55 Re: Possible Bug in pg_upgrade
Previous Message Greg Smith 2011-08-15 00:53:02 Re: our buffer replacement strategy is kind of lame