Re: Snapshot synchronization, again... - Mailing list pgsql-hackers
From | Alvaro Herrera |
---|---|
Subject | Re: Snapshot synchronization, again... |
Date | |
Msg-id | 1298406311-sup-5625@alvh.no-ip.org Whole thread Raw |
In response to | Re: Snapshot synchronization, again... (Robert Haas <robertmhaas@gmail.com>) |
Responses |
Re: Snapshot synchronization, again...
|
List | pgsql-hackers |
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.) 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. 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. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
pgsql-hackers by date: