Josh Berkus <j...@agliodbs.com> wrote: > Well, we *still* want predicate locking regardless of what MERGE > supports. It's useful in about 9 different ways. I don't know whether this is the right time to discuss those 9 different uses, but just so everyone knows, the SIRead locks needed for the SSI implementation in the current serializable patch have some characteristics which may be exactly what you want (if you want cache invalidation or some such) or may render them totally useless from some purposes. (1) They don't block anything. Ever. Conflicts with writes are detected, and right now that is used to mark rw-conflicts between serializable transactions. I assume we may want to add listeners who can be signaled on such conflicts, too; but that isn't there now. (2) They are only acquired by serializable transactions. (3) They can survive the transaction which acquired them, and even the termination of the process which ran the transaction. Right now they go away when the last serializable transaction which overlapped the acquiring serializable transaction completes. If we add listeners, I assume we'd want to keep them as long as a listener was registered, probably with some timeout feature. Just so everyone knows what is and isn't there right now. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers