On 08/17/2017 12:20 AM, Tom Lane wrote:
Andres Freund <and...@anarazel.de> writes:
On 2017-08-16 16:20:28 +0300, Heikki Linnakangas wrote:
+ pg_atomic_write_u64(&target->phs_nallocated, 0);
It's not ok to initialize an atomic with pg_atomic_write_u64 - works
well enough for "plain" atomics, but the fallback implementation isn't
ok with it. You're probably going to get a failure on the respective
buildfarm animal soon.
Indeed, gaur fails with
2017-08-16 17:09:38.315 EDT [13043:11] PANIC: stuck spinlock detected at pg_at\
omic_compare_exchange_u64_impl, atomics.c:196
2017-08-16 17:09:38.315 EDT [13043:12] STATEMENT: select count(*) from a_star;
2017-08-16 17:09:40.350 EDT [12437:3] LOG: server process (PID 13043) was term\
inated by signal 6
2017-08-16 17:09:40.350 EDT [12437:4] DETAIL: Failed process was running: sele\
ct count(*) from a_star;
and I'm sure pademelon will fail once it gets to that.
Fixed.
I thought we had other buildfarm animals testing the fallback path,
though?
Yes, at least piculet is building with --disable-atomics.
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.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
