| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Florian Pflug <fgp(at)phlo(dot)org>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
| Subject: | Re: Memory ordering issue in LWLockRelease, WakeupWaiters, WALInsertSlotRelease |
| Date: | 2014-02-15 15:18:00 |
| Message-ID: | 20140215151800.GD16968@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2014-02-15 10:06:41 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > My current conclusion is that backporting barriers.h is by far the most
> > reasonable way to go. The compiler problems have been ironed out by
> > now...
>
> -1. IMO that code is still quite unproven, and what's more, the
> problem we're discussing here is completely hypothetical. If it
> were real, we'd have field evidence of it. We've not had that
> much trouble seeing instances of even very narrow race-condition
> windows in the past.
Well, the problem is that few of us have access to interesting !x86
machines to run tests, and that's where we'd see problems (since x86
gives enough guarantees to avoid this unless the compiler reorders
stuff). I am personally fine with just using volatiles to avoid
reordering in the older branches, but Florian argued against it.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2014-02-15 15:22:33 | Re: Create function prototype as part of PG_FUNCTION_INFO_V1 |
| Previous Message | Tom Lane | 2014-02-15 15:16:50 | Re: narwhal and PGDLLIMPORT |