Re: Shared memory size computation oversight?

On 12.08.21 16:18, Julien Rouhaud wrote:
> On Thu, Aug 12, 2021 at 9:34 PM Peter Eisentraut
> <peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
>>
>> On 27.02.21 09:08, Julien Rouhaud wrote:
>>> PFA a patch that fixes pg_prewarm and pg_stat_statements explicit alignment to
>>> CACHELINEALIGN, and also update the alignment in hash_estimate_size() to what I
>>> think ShmemInitHash will actually consume.
>>
>> For extensions, wouldn't it make things better if
>> RequestAddinShmemSpace() applied CACHELINEALIGN() to its argument?
>>
>> If you consider the typical sequence of RequestAddinShmemSpace(mysize())
>> and later ShmemInitStruct(..., mysize(), ...),
>
> But changing RequestAddinShmemSpace() to apply CACHELINEALIGN() would
> only really work for that specific usage only? If an extension does
> multiple allocations you can't rely on correct results.

I think you can do different things here to create inconsistent results,
but I think there should be one common, standard, normal,
straightforward way to get a correct result.

>> Btw., I think your patch was wrong to apply CACHELINEALIGN() to
>> intermediate results rather than at the end.
>
> I'm not sure why you think it's wrong. It's ShmemInitStruct() that
> will apply the padding, so if the extension calls it multiple times
> (whether directly or indirectly), then the padding will be added
> multiple times. Which means that in theory the extension should
> account for it multiple time in the amount of memory it's requesting.

Yeah, in that case it's probably rather the case that there is one
CACHELINEALIGN() too few, since pg_stat_statements does two separate
shmem allocations.