"Markus Wanner" <[email protected]> wrote: > What I'm more concerned is the requirement of the proposed algorithm > to keep track of the set of tuples read by any transaction and keep > that set until sometime well after the transaction committed (as > questioned by Neil). That doesn't sound like a negligible overhead. Quick summary for those who haven't read the paper: with this non-blocking technique, every serializable transaction which successfully commits must have its read locks tracked until all serializable transactions which are active at the commit also complete. In the prototype implementation, I think they periodically scanned to drop old transactions, and also did a final check right before deciding there is a conflict which requires rollback, cleaning up the transaction if it had terminated after the last scan but in time to prevent a problem. -Kevin
-- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
