On Sun, May 8, 2011 at 8:31 PM, Dan Ports 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 PostgreSQL Co
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 b/src/backend/storage/lm
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 SHM
On Thu, May 5, 2011 at 1:43 PM, Kevin Grittner
wrote:
> Dan Ports 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
>> SI
Dan Ports 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. There's an
> o
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 w
