On Fri, 2010-05-21 at 16:08 +0800, Craig Ringer wrote: > My non-expert feeling is that you could possibly extend a predicate > locking scheme to do this. It's something that'd maybe be possible by > hooking into the predicate locking schemes being being designed to > support true serializability in Pg (see periodic discussion on -hackers) > but those locking schemes aren't in the main PG code yet. Thanks for that. Gives me a place to start looking! > It might be a good idea to take a few steps back and look at what you > are trying to achieve with this. Why do you want it? What for? What > problem will it solve for you? It's not a typical application-level problem. I'm playing with the idea of extending the transactional memory system in the Haskell programming language so that database access can be done inside of an application atomic block. Currently, database access counts as I/O, and therefore must be done outside of atomic blocks, and this leads to a somewhat strained programming model for applications combining transactional memory with databases. Haskell's transactional memory provides exactly the feature I'm asking for: specifically, there is a "retry" action, which rolls back a transaction, blocks until there's some change that makes it likely that the transaction will behave differently in the future, and then retries it. This turns out to be very useful for transactional memory. Whether it's useful for database access or not may be an open question, but it seems very messy to say "don't retry if you've touched the database", since the point here is to be composable and not make people worry about the implementation details of some other part of their transactions. -- Chris Smith -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
