Re: Snapshot synchronization, again... - Mailing list pgsql-hackers

On Tue, Feb 22, 2011 at 8:55 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> The current discussion seems to have reached the same conclusion as the
> last one: the snapshot info shouldn't leave the server, but be
> transmitted internally -- the idea of the temp file seems prevalent.
> Here's an attempt at a detailed spec:
>
> By invoking pg_export_snapshot(), a transaction can export its current
> transaction snapshot.
>
> To export a snapshot, the transaction creates a temp file containing all
> information about the snapshot, including the BackendId and
> TransactionId of the creating transaction.  The file name is determined
> internally by the exporting transaction, and returned by the function
> that creates the snapshot.  The act of exporting a snapshot causes a
> TransactionId to be acquired, if there is none.
>
> Care is taken that no existing snapshot file is ever overwritten, to
> prevent security problems.  A transaction may export any number of
> snapshots.
>
> The "cookie" to be passed around, then, is a temp file identifier.  This
> cookie gets passed as START TRANSACTION (snapshot='foo'), which sets the
> transaction's snapshot to the one determined by the identifier.  The
> importing transaction must have isolation level serializable or
> repeatable read declared on the same START TRANSACTION command; an
> attempt to import a snapshot into a read committed transaction or one
> with unspecified isolation level causes the transaction to get into
> aborted state (so you still need to say ROLLBACK to get out of it.  This
> is necessary to avoid the session to proceed involuntarily with the
> wrong snapshot.)
>
> Similarly, if the snapshot is not available, an error is raised and the
> transaction block remains in aborted state.  This can happen if the
> originating transaction ended after you opened the file, for example.
> The BackendId and TransactionId of the exporting transaction let the
> importing backend determine the validity of the snapshot beyond the mere
> existence of the file.
>
> The snapshot temp file is to be marked for deletion on transaction end.
> All snapshot temp files are also deleted on crash recovery, to prevent
> dangling files (I need some help here to determine how this plays with
> hot standby.)

I think this can be done within StartupXLOG(), right around where we
ResetUnloggedRelations(UNLOGGED_RELATION_CLEANUP).

> Privileges: Any role can export or import a snapshot.  The rationale
> here is that exporting a snapshot doesn't cause any more harm than
> holding a transaction open, so if you let your users do that, then
> there's no extra harm.  Similarly, there's no extra privilege given to a
> role that imports a snapshot that cannot be obtained by sending a START
> TRANSACTION command at the right time.

Agree.

> Note: this proposal doesn't mention restrictions on having
> subtransactions in the exporting transaction.  This is because I haven't
> figured them out, not because I think there shouldn't be any.

I think it's probably sufficient to say that a snapshot can only be
exported from the toplevel transaction.

Overall, this proposal is fine with me.  But then I wasn't the one who
complained about it last time.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company