Excerpts from Joachim Wieland's message of jue dic 30 09:31:47 -0300 2010: > Advantage of b: No validation necessary, as soon as the transaction > that publishes the snapshot loses that snapshot, it will also revoke > the snapshot information (either by removing a temp file or deleting > it from shared memory) > Disadvantage of b: It doesn't allow a snapshot to be installed on a > different server. It requires a serializable open transaction to hold > the snapshot.
Why does it require a serializable transaction? You could simply register the snapshot in any transaction. (Of course, the net effect would be pretty similar to a serializable transaction). > We return snapshot information as a chunk of data to the client. At > the same time however, we set a checksum in shared memory to protect > against modification of the snapshot. A publishing backend can revoke > its snapshot by deleting the checksum and a backend that is asked to > install a snapshot can verify that the snapshot is correct and current > by calculating the checksum and comparing it with the one in shared > memory. > > This only costs us a few bytes for the checksum * max_connection in > shared memory and apart from resetting the checksum it does not have > cleanup and verification issues. So one registered snapshot per transaction? Sounds a reasonable limitation (I doubt there's a use case for more than that, anyway). -- Álvaro Herrera <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
