Composing my rather long-winded response to Simon got me thinking -- which just led me to realize there is probably a need to fix another thing related to SSI. For correct serializable behavior in the face of concurrent DDL execution, I think that a request for a heavyweight ACCESS EXCLUSIVE lock might need to block until all SIREAD locks on the relation have been released. Picture, for example, what might happen if one transaction acquires some predicate locks, then commits (releasing its heavyweight lock on the table), and before concurrent READ WRITE transactions complete there is a CLUSTER on the table. Or a DROP INDEX. :-( Both require an ACCESS EXCLUSIVE lock. Since an active transaction would already have an ACCESS SHARE lock when acquiring the SIREAD locks, this couldn't block in the other direction or with an active transaction. That means that it couldn't cause any deadlocks if we added blocking to the acquisition of an ACCESS EXCLUSIVE based on this. If we don't do this I don't think that there is a more serious impact than inaccurate conflict detection for serializable transactions which are active when these operations are performed. Well, that and the possibility of seeing SIRead locks in the pg_locks view for indexes or tables which no longer exist. So far I don't see any crash modes or effects on non-serializable transactions. If this change is too destabilizing for this point in the release we could document it as a limitation and fix it in 9.2. We're pretty aggressive about cleaning up SIREAD locks as soon as allowable after transaction completion, so this probably wouldn't happen very often. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers