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. 6b93fcd149329d4ee7319561b30fc15a573c
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 great idea about addr
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 just an unlocked
> >
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, because it has to cause
>
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 without proper locks...
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 ...
regards,
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
> PO
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 symbol 'sem_post@@GLI
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. It's a bit hard to tell
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 tha
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 at
11 matches
Mail list logo
