Re: Obsolete use of volatile in walsender.c, walreceiver.c, walreceiverfuncs.c?

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Obsolete use of volatile in walsender.c, walreceiver.c, walreceiverfuncs.c?
Date: 2015-10-02 03:01:39
Message-ID: CAB7nPqT2QCkQ80LOKv5VJn91VcrL0E-EMygfRivQFSaMe4deTw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 22, 2015 at 7:25 AM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> On Tue, Sep 22, 2015 at 8:19 AM, Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)com> wrote:
>> Thomas Munro wrote:
>>
>>> In walsender.c, walreceiver.c, walreceiverfuncs.c there are several
>>> places where volatile qualifiers are used apparently only to prevent
>>> reordering around spinlock operations.
>>
>> In replication/slot.c there are a number of places (12, I think) that
>> introduce a block specifically to contain a volatile cast on a variable
>> for spinlock-protected access. We could remove the whole thing and save
>> at least 3 lines and one indentation level for each of them.
>
> Right, see attached.

It seems to me that we could as well simplify checkpoint.c and
logical.c. In those files volatile casts are used as well to protect
from reordering for spinlock operations. See for example 0002 on top
of 0001 that is Thomas' patch.
--
Michael

Attachment Content-Type Size
0001-Remove-obsolete-use-of-volatile-in-WAL-related-files.patch text/x-patch 13.9 KB
0002-Remove-use-of-volatile-for-spinlock-operations-in-mo.patch text/x-patch 8.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2015-10-02 03:06:03 Re: [DOCS] max_worker_processes on the standby
Previous Message Kyotaro HORIGUCHI 2015-10-02 00:50:02 Re: Foreign join pushdown vs EvalPlanQual