From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Boszormenyi Zoltan <zb(at)cybertec(dot)at>, Stephen Frost <sfrost(at)snowman(dot)net>, Hari Babu <haribabu(dot)kommi(at)huawei(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Hans-Jürgen Schönig <hs(at)cybertec(dot)at>, Ants Aasma <ants(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Amit kapila <amit(dot)kapila(at)huawei(dot)com> |
Subject: | Re: Strange Windows problem, lock_timeout test request |
Date: | 2013-03-22 00:16:39 |
Message-ID: | 17142.1363911399@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Mar 18, 2013 at 10:09 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Because it's wrong. Removing "volatile" means that the compiler is
>> permitted to optimize away stores (and fetches!) on the basis of their
>> being unnecessary according to straight-line analysis of the code.
>> Write barriers don't fix that, they only say that stores that the
>> compiler chooses to issue at all have to be ordered a certain way.
> I don't think this is correct. The read and write barriers as
> implemented are designed to function as compiler barriers also, just
> as they do in the Linux kernel and every other piece of software I've
> found that implements anything remotely like this, with the lone
> exception of PostgreSQL. In PostgreSQL, spinlock acquisition and
> release are defined as CPU barriers but not a compiler barrier, and
> this necessitates extensive use of volatile all over the code base
> which would be unnecessary if we did this the way it's done in Linux
> and elsewhere.
I think you're just as mistaken as Zoltan. Barriers enforce ordering
of operations, not whether an operation occurs at all.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2013-03-22 01:04:45 | Re: Enabling Checksums |
Previous Message | Michael Paquier | 2013-03-21 22:38:36 | Re: Support for REINDEX CONCURRENTLY |