Re: [HACKERS] Our "fallback" atomics implementation doesn't actually work

On 2016-10-07 17:12:45 -0400, Tom Lane wrote: > Andres Freund writes: > > It's not quite there yet, unfortunately. At the moment > > pg_atomic_write_u32() is used for local buffers - and we explicitly > > don't want that to be locking for temp buffers > > (c.f.

Re: [HACKERS] Our "fallback" atomics implementation doesn't actually work

Andres Freund writes: > It's not quite there yet, unfortunately. At the moment > pg_atomic_write_u32() is used for local buffers - and we explicitly > don't want that to be locking for temp buffers > (c.f. 6b93fcd149329d4ee7319561b30fc15a573c6307). Hm. > Don't really have a

Re: [HACKERS] Our "fallback" atomics implementation doesn't actually work

On 2016-10-06 00:06:33 -0400, Tom Lane wrote: > Andres Freund writes: > > Hm. After a long battle of head vs. wall I think I see what the problem > > is. For the fallback atomics implementation I somehow had assumed that > > pg_atomic_write_u32() doesn't need to lock, as it's

Re: [HACKERS] Our "fallback" atomics implementation doesn't actually work

Andres Freund writes: > Hm. After a long battle of head vs. wall I think I see what the problem > is. For the fallback atomics implementation I somehow had assumed that > pg_atomic_write_u32() doesn't need to lock, as it's just an unlocked > write. But that's not true,

Re: [HACKERS] Our "fallback" atomics implementation doesn't actually work

On 2016-10-05 15:02:09 -0400, Tom Lane wrote: > Andres Freund writes: > > Without yet having analyzed this deeply, could it actually be that the > > reason is that sem_post/wait aren't proper memory barriers? On a glance > > the symptoms look like values have been modified

Re: [HACKERS] Our "fallback" atomics implementation doesn't actually work

Andres Freund writes: > Without yet having analyzed this deeply, could it actually be that the > reason is that sem_post/wait aren't proper memory barriers? On a glance > the symptoms look like values have been modified without proper locks... Hmm, possible ...

Re: [HACKERS] Our "fallback" atomics implementation doesn't actually work

Hi, I was able to reproduce it in a read-write workload, instead of the read-only workload you'd proposed. On 2016-10-05 14:01:05 -0400, Tom Lane wrote: > Curiously, I did not see such a hang with regular SysV semaphores. > That may be just a timing thing, or it may have something to do with >

Re: [HACKERS] Our "fallback" atomics implementation doesn't actually work

Andres Freund writes: > On 2016-10-05 14:01:05 -0400, Tom Lane wrote: >> configure USE_UNNAMED_POSIX_SEMAPHORES=1 --disable-cassert >> --disable-spinlocks --disable-atomics > Pretty independent from the complaint at hand, but if I just do that I get > undefined reference to

Re: [HACKERS] Our "fallback" atomics implementation doesn't actually work

Andres Freund writes: > On 2016-10-05 14:01:05 -0400, Tom Lane wrote: >> I think what is happening is that there are circular assumptions that end >> up trying to implement a spinlock in terms of a spinlock, or otherwise >> somehow recursively use the process's semaphore.

Re: [HACKERS] Our "fallback" atomics implementation doesn't actually work

On 2016-10-05 14:01:05 -0400, Tom Lane wrote: > I was trying to measure whether unnamed POSIX semaphores are any faster > or slower than the SysV kind. Plain pgbench is not very helpful for > determining this, because we've optimized the system to the point that > you don't hit semop waits all

Re: [HACKERS] Our "fallback" atomics implementation doesn't actually work

Hi, On 2016-10-05 14:01:05 -0400, Tom Lane wrote: > I think what is happening is that there are circular assumptions that end > up trying to implement a spinlock in terms of a spinlock, or otherwise > somehow recursively use the process's semaphore. It's a bit hard to tell > though because the

[HACKERS] Our "fallback" atomics implementation doesn't actually work

I was trying to measure whether unnamed POSIX semaphores are any faster or slower than the SysV kind. Plain pgbench is not very helpful for determining this, because we've optimized the system to the point that you don't hit semop waits all that often. So I tried this: configure