Re: Atomics for heap_parallelscan_nextpage()

On 08/17/2017 12:20 AM, Tom Lane wrote:
> Andres Freund <andres@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