回复: Fix segfault while accessing half-initialized hash table in pgstat_shmem.c
Steven Niu <niushiji@gmail.com>
From: Steven Niu <niushiji@gmail.com>
To: Mikhail Kot <mikhail.kot@databricks.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Cc: "to@myrrc.dev" <to@myrrc.dev>
Date: 2025-09-04T02:31:34Z
Lists: pgsql-hackers
Hi, Mikhail, If pgstat_init_entry() errors on OOM, what would it returns to shheader, NULL? That would bring trouble to dshash_delete_entry(). Thanks, Steven ________________________________ 发件人: Mikhail Kot <mikhail.kot@databricks.com> 已发送: 2025 年 9 月 04 日 星期四 05:39 收件人: pgsql-hackers@lists.postgresql.org <pgsql-hackers@lists.postgresql.org> 抄送: to@myrrc.dev <to@myrrc.dev> 主题: Re: Fix segfault while accessing half-initialized hash table in pgstat_shmem.c 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 calling pgstat_lock_entry() through pgstat_get_entry_ref() which accesses a non-initialized lock. Here's the second version of the patch. Now we remove inserted hash entry on OOM which would prevent accessing the entry
Commits
-
Fix corruption of pgstats shared hashtable due to OOM failures
- 1852ec5db5d8 15.15 landed
- 12f57681c79b 16.11 landed
- 3e6dfcfb0529 17.7 landed
- f256a7bba728 18.0 landed
- 8191e0c16a03 19 (unreleased) landed