On August 16, 2017 3:09:27 PM PDT, Tom Lane <t...@sss.pgh.pa.us> wrote: >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.
We kind of do - crash restarts... So yes, that's probably a good idea. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
