On Sun, May 8, 2011 at 8:31 PM, Dan Ports d...@csail.mit.edu wrote:
On Fri, May 06, 2011 at 10:49:22PM -0400, Dan Ports wrote:
Will update the patch.
Updated patch (in response to Robert's comments) attached.
Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
On Fri, May 06, 2011 at 10:49:22PM -0400, Dan Ports wrote:
Will update the patch.
Updated patch (in response to Robert's comments) attached.
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
diff --git a/src/backend/storage/lmgr/predicate.c
On Thu, May 5, 2011 at 1:43 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Dan Ports d...@csail.mit.edu wrote:
While running some benchmarks to test SSI performance, I found a
race condition that's capable of causing a segfault. A patch is
attached.
The bug is in
On Fri, May 06, 2011 at 09:35:39PM -0400, Robert Haas wrote:
Why does this HASH_FIND the applicable hash table entries and then
HASH_REMOVE it as a separate step, instead of just HASH_REMOVE-ing it
in one go?
For PredicateLockHash, we need to find the lock entry first so that we
can call
Dan Ports d...@csail.mit.edu wrote:
While running some benchmarks to test SSI performance, I found a
race condition that's capable of causing a segfault. A patch is
attached.
The bug is in CheckTargetForConflictsIn, which scans the list of
SIREAD locks on a lock target when it's modified.
While running some benchmarks to test SSI performance, I found a race
condition that's capable of causing a segfault. A patch is attached.
The bug is in CheckTargetForConflictsIn, which scans the list of SIREAD
locks on a lock target when it's modified. There's an optimization in
there where the
