Hi Michael, Steven, and Ranier,
> Anyway, couldn't we flip the order of the operations in
pgstat_init_entry() so as we do first an allocation and avoid any inconsistency
in the shared state?
The issue is not only in pgstat_init_entry(). Currently it errors on OOM but
this doesn't prevent us from
On Wed, Sep 03, 2025 at 10:39:04PM +0100, Mikhail Kot wrote:
> The issue is not only in pgstat_init_entry(). Currently it errors on OOM but
> this doesn't prevent us from calling pgstat_lock_entry() through
> pgstat_get_entry_ref() which accesses a non-initialized lock.
Spent more time on that, fi
Em qua., 3 de set. de 2025 às 03:34, Mikhail Kot
escreveu:
> Hi,
>
> I've encountered the following segmentation fault lately. It happens when
> Postgres is experiencing high memory pressure. There are multiple OOM
> errors in
> the log as well.
>
> Core was generated by `postgres: neondb_owner n
On Tue, Sep 02, 2025 at 09:09:54PM +0100, Mikhail Kot wrote:
> The error originates from pgstat_shmem.c file where shhashent is left in
> half-initialized state if pgstat_init_entry(), calling dsa_allocate0(), errors
> out with OOM. Then shhashent causes a segmentation fault on access. I propose
>
