"Albe Laurenz" <laurenz.a...@wien.gv.at> writes: > So I think one would have to add intention locks for rows considered > in the WHERE clause to guarantee true serializability.
Does the paper explain how to deal with rows "considered" in the WHERE clause which don't yet exist? Ie, "SELECT count(*) WHERE foo" needs to take out a lock which would cause any transaction which inserts a new record where foo is true to be abort. In MSSQL this requires locking the page of the index where such records would be inserted (or the entire table if there's no index). In Predicate locking schemes this requires a separate storage structure for storing such predicates which can be arbitrarily complex expressions to check any new tuple being inserted against. Are these intention locks predicate locks, in that they're not associated with actual pages or records but with potential records which might be inserted in the future? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
