Robert Haas writes:
> On Wed, Mar 26, 2014 at 12:59 AM, Robert Haas wrote:
>> It seems to me that the simplest thing to do might be
>> just this:
>>
>> -static FastPathStrongRelationLockData *FastPathStrongRelationLocks;
>> +static volatile FastPathStrongRelationLockData *FastPathStrongRelationL
On Wed, Mar 26, 2014 at 12:59 AM, Robert Haas wrote:
> It seems to me that the simplest thing to do might be
> just this:
>
> -static FastPathStrongRelationLockData *FastPathStrongRelationLocks;
> +static volatile FastPathStrongRelationLockData *FastPathStrongRelationLocks;
>
> Do you see any prob
On 03/26/2014 06:59 AM, Robert Haas wrote:
On Tue, Mar 25, 2014 at 11:58 AM, Tom Lane wrote:
Robert Haas writes:
I really think we
should change that rule; it leads to ugly code, and bugs.
No doubt, but are we prepared to believe that we have working "compiler
barriers" other than volatile?
On Tue, Mar 25, 2014 at 11:58 AM, Tom Lane wrote:
> Robert Haas writes:
>> Well, it's possible that the issue could be related to compiler
>> reordering, since it's still the rule that SpinLockAcquire/Release
>> must be memory barriers but need not be compiler barriers, and
>> FastPathStrongRelat
Robert Haas writes:
> On Tue, Mar 25, 2014 at 10:09 AM, Tom Lane wrote:
>> Since this machine has only been running the buildfarm for a week,
>> I rather imagine we will see more of these. Thoughts?
>>
>> (This is a PPC machine, but only a single processor, so it's hard
>> to see how memory ord
On Tue, Mar 25, 2014 at 10:09 AM, Tom Lane wrote:
> Buildfarm member prairiedog crashed on today's HEAD with this:
>
> TRAP: FailedAssertion("!(FastPathStrongRelationLocks->count[fasthashcode] >
> 0)", File: "lock.c", Line: 1240)
>
> I have the core file, and gdb says:
>
> #0 0x90047dac in kill
