From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Our "fallback" atomics implementation doesn't actually work |
Date: | 2016-10-07 18:40:07 |
Message-ID: | 20161007184007.54cqoed2jwln76wh@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2016-10-06 00:06:33 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> 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
> > pg_atomic_compare_exchange_u32 to fail.
>
> Hah ... obvious once you see it.
>
> > For me the problem often takes a lot longer to reproduce (once only
> > after 40min), could you run with the attached patch, and see whether
> > that fixes things for you?
>
> For me, with the described test case, HEAD fails within a minute,
> two times out of three or so. I've not reproduced it after half an
> hour of beating on this patch. Looks good.
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).
Don't really have a great idea about addressing this, besides either
just living with the lock for temp buffers on fallback platforms (which
don't have much of a practical relevance), or introduce
pg_atomic_unlocked_write_u32() or something. Neither seems great.
Regards,
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2016-10-07 18:56:27 | Re: CVE-2016-1238 fix breaks (at least) pg_rewind tests |
Previous Message | Steve Crawford | 2016-10-07 18:08:39 | Re: Is it time to kill support for very old servers? |