Re: Better shared data structure management and resizable shared data structures - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Better shared data structure management and resizable shared data structures
Date
Msg-id 34d1acd9-0aff-4d59-ada3-a583e1173043@iki.fi
Whole thread Raw
In response to Re: Better shared data structure management and resizable shared data structures  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
List pgsql-hackers
On 05/04/2026 02:17, Matthias van de Meent wrote:
>> +    pgss->extent = 0;
>> +    pgss->n_writers = 0;
>> +    pgss->gc_count = 0;
>> +    pgss->stats.dealloc = 0;
> 
> Shmem is said to be zero-initialized, should we remove the manual
> zero-initialization?

Yeah, perhaps. We already had initialization like this in many places, 
while others relied on the implicit initialization. Some places even do 
just this:

void
LogicalDecodingCtlShmemInit(void)
{
    bool        found;

    LogicalDecodingCtl = ShmemInitStruct("Logical decoding control",
                                         LogicalDecodingCtlShmemSize(),
                                         &found);

    if (!found)
        MemSet(LogicalDecodingCtl, 0, LogicalDecodingCtlShmemSize());
}

I think there are two directions we could go here:

1. Document that the memory is zeroed, and you can rely on it. Remove 
silly initializations like that in LogicalDecodingCtlShmemInit(). In 
other places the explicitly zero-initialization might have documentation 
value though.

2. Require the init functions to explicitly zero the memory. Document it 
and add valgrind checks.

I'm inclined to go with 1. But in the name of avoiding scope creep, not 
as part of these patches.

- Heikki




pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)
Next
From: Sami Imseih
Date:
Subject: Re: Duplicate RequestNamedLWLocktranche() names and test_lwlock_tranches improvements