Re: Still something fishy in the fastpath lock stuff

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Mar 25, 2014 at 10:09 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 ordering issues might enter into it ...)

> 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
> FastPathStrongRelationLocks is not volatile-ized.

Yeah, I was just about to complain about that. What made you think
you could get away with ignoring that coding rule?

> 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? (Which, I will remind you, is in the C
standard. Unlike "compiler barriers".)

> But to
> determine whether that's the issue, we'd probably need to disassemble
> the relevant code and see whether the compiler did in fact shift
> things around.

I looked at the asm code around line 1240, and it seems all right, but
if this is a locking problem then the actual failure was probably in some
preceding spinlocked segment. I haven't the patience to look at each one
of these segments, and it's sort of irrelevant anyway, because whether
this particular machine did reorder the asm code or not, the fact remains
that *this C code is broken*. The fact that you don't like the existing
coding rules concerning spinlocks is not license to write unsafe code.

regards, tom lane