From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: unconstify equivalent for volatile |
Date: | 2019-02-19 15:00:58 |
Message-ID: | d3be3509-9248-4afe-d6de-4ed83a7553de@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2019-02-18 21:25, Andres Freund wrote:
> ISTM this one should rather be solved by removing all volatiles from
> latch.[ch]. As that's a cross-process concern we can't rely on it
> anyway (and have placed barriers a few years back to allay concerns /
> bugs due to reordering).
Aren't the volatiles there so that Latch variables can be set from
signal handlers?
>> diff --git a/src/backend/storage/ipc/pmsignal.c b/src/backend/storage/ipc/pmsignal.c
>> index d707993bf6..48f4311464 100644
>> --- a/src/backend/storage/ipc/pmsignal.c
>> +++ b/src/backend/storage/ipc/pmsignal.c
>> @@ -134,7 +134,7 @@ PMSignalShmemInit(void)
>>
>> if (!found)
>> {
>> - MemSet(PMSignalState, 0, PMSignalShmemSize());
>> + MemSet(unvolatize(PMSignalData *, PMSignalState), 0, PMSignalShmemSize());
>> PMSignalState->num_child_flags = MaxLivePostmasterChildren();
>> }
>> }
>
> Same. Did you put an type assertion into MemSet(), or how did you
> discover this one as needing to be changed?
Build with -Wcast-qual, which warns for this because MemSet() does a
(void *) cast.
> .oO(We really ought to remove MemSet()).
yeah
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2019-02-19 15:14:06 | Re: CPU costs of random_zipfian in pgbench |
Previous Message | Fabien COELHO | 2019-02-19 14:56:58 | Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" test pending solution of its timing is (fwd) |