Re: Obsolete use of volatile in walsender.c, walreceiver.c, walreceiverfuncs.c? - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Obsolete use of volatile in walsender.c, walreceiver.c, walreceiverfuncs.c?
Date
Msg-id CAB7nPqT2QCkQ80LOKv5VJn91VcrL0E-EMygfRivQFSaMe4deTw@mail.gmail.com
Whole thread Raw
In response to Re: Obsolete use of volatile in walsender.c, walreceiver.c, walreceiverfuncs.c?  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: Obsolete use of volatile in walsender.c, walreceiver.c, walreceiverfuncs.c?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, Sep 22, 2015 at 7:25 AM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Tue, Sep 22, 2015 at 8:19 AM, Alvaro Herrera
> <alvherre@2ndquadrant.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

pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Foreign join pushdown vs EvalPlanQual
Next
From: Fujii Masao
Date:
Subject: Re: [DOCS] max_worker_processes on the standby