Heikki Linnakangas <hlinn...@iki.fi> writes:
> On 08/17/2017 12:20 AM, Tom Lane wrote:
>> Indeed, gaur fails with
>> 2017-08-16 17:09:38.315 EDT [13043:11] PANIC: stuck spinlock detected at
>> pg_atomic_compare_exchange_u64_impl, atomics.c:196
> I was able to reproduce this locally, with --disable-atomics, but only
> after hacking it to fill the struct with garbage, before initializing
> it. IOW, it failed to fail, because the spinlock happened to be
> initialized correctly by accident. Perhaps that's happening on piculet, too.
Oh, right. HPPA is unique among our platforms, I think, in that the
"unlocked" state of a spinlock is not "all zeroes". So if you're dealing
with pre-zeroed memory, which shmem generally would be, failing to
initialize a spinlock does not cause visible errors except on HPPA.
I wonder whether it's sensible to have --enable-cassert have the effect
of filling memory allocated by ShmemAlloc or the DSA code with junk (as
palloc does) instead of leaving it at zeroes. It's not modeling the
same kind of effect, since we have no shmem-freeing primitives, but
it might be useful for this sort of thing.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
