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
