On 26.12.2010 21:40, Kevin Grittner wrote:
To recap, I've had an open question on the Serializable Wiki page[1] since January about how we should handle long-running transactions. The algorithm published by Cahill et al requires keeping some transaction information in memory for all committed transactions which overlapped a still-running transaction. Since we need to keep this in shared memory, and the structures must have a finite allocation, there's an obvious looming limit, even if the allocation is relatively generous.
Looking at the predicate lock splitting, it occurs to me that it's possible for a non-serializable transaction to be canceled if it needs to split a predicate lock held by a concurrent serializable transaction, and you run out of space in the shared memory predicate lock area. Any chance of upgrading the lock to a relation lock, or killing the serializable transaction instead?
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
