Shared memory size computation oversight?

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: robertmhaas(at)gmail(dot)com
Subject: Shared memory size computation oversight?
Date: 2021-02-27 08:08:15
Message-ID: 20210227080815.jryyhy6lrn6gahkm@nol
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

While investigating on some strange "out of shared memory" error reported on
the french BBS [1], I noticed that 09adc9a8c09 (adding Robert in Cc) changed
ShmemAlloc alignment to CACHELINEALIGN but didn't update any related code that
depended on it.

Most of the core code isn't impacted as it doesn't have to reserve any shared
memory, but AFAICT pg_prewarm and pg_stat_statements can now slightly
underestimate the amount of shared memory they'll use, and similarly for any
third party extension that still rely on MAXALIGN alignment. As a consequence
those extension can consume a few hundred bytes more than they reserved, which
probably will be borrowed from the lock hashtables reserved size that isn't
alloced immediately. This can later lead to ShmemAlloc failing when trying to
acquire a lock while the hash table is almost full but should still have enough
room to store it, which could explain the error reported.

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.

[1] https://forums.postgresql.fr/viewtopic.php?pid=32138#p32138 sorry, it's all
in French.

Attachment Content-Type Size
v1-0001-Fix-various-shared-memory-computation.patch text/x-diff 2.7 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2021-02-27 08:30:09 Re: Remove latch.c workaround for Linux < 2.6.27
Previous Message Heikki Linnakangas 2021-02-27 08:01:27 Re: Remove latch.c workaround for Linux < 2.6.27