From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | pgsql-hackers(at)postgresql(dot)org, drkp(at)csail(dot)mit(dot)edu |
Subject: | Re: SSI memory mitigation & false positive degradation |
Date: | 2010-12-29 17:57:05 |
Message-ID: | 4D1B7671.2070108@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-12-29 18:01:54 | Re: pg_streamrecv for 9.1? |
Previous Message | David Fetter | 2010-12-29 17:56:33 | Re: Avoiding rewrite in ALTER TABLE ALTER TYPE |