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

In response to

• SSI memory mitigation & false positive degradation at 2010-12-26 19:40:15 from Kevin Grittner

Responses

• Re: SSI memory mitigation & false positive degradation at 2010-12-29 18:05:00 from Kevin Grittner

pgsql-hackers by date

Next:	From: Tom Lane	Date: 2010-12-29 18:01:54
	Subject: Re: pg_streamrecv for 9.1?
Previous:	From: David Fetter	Date: 2010-12-29 17:56:33
	Subject: Re: Avoiding rewrite in ALTER TABLE ALTER TYPE