回复: 回复: Fix segfault while accessing half-initialized hash table in pgstat_shmem.c
От | Steven Niu |
---|---|
Тема | 回复: 回复: Fix segfault while accessing half-initialized hash table in pgstat_shmem.c |
Дата | |
Msg-id | MN2PR15MB3021358255AE244C3D362247A701A@MN2PR15MB3021.namprd15.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: 回复: Fix segfault while accessing half-initialized hash table in pgstat_shmem.c (Michael Paquier <michael@paquier.xyz>) |
Список | pgsql-hackers |
________________________________________ 发件人: Michael Paquier 已发送: 2025 年 9 月 03 日 星期三 17:43 收件人: Steven Niu 抄送: Mikhail Kot; pgsql-hackers@lists.postgresql.org; to@myrrc.dev 主题: Re: 回复: Fix segfault while accessing half-initialized hash table in pgstat_shmem.c On Wed, Sep 03, 2025 at 07:22:00AM +0000, Steven Niu wrote: > So unless dsa_allocate() can ensure never returns InvalidDsaPointer, > there is risk of SegV. In fact the function dsa_allocate() does > return InvalidDsaPointer in some cases. > > So, maybe should we add pointer check in all places where dsa_get_address is called. Comments? dsa_allocate() calls dsa_allocate_extended() without DSA_ALLOC_NO_OOM, hence on allocation failure the code does a ereport(ERROR). It would be a problem to not check the result if DSA_ALLOC_NO_OOM is used. Thanks, Michael, you are correct. The problem dealt with here is different, as far as I understand: we set some data in shared memory without considering that the DSA allocation could fail, leaving shared memory in an inconsistent state when an allocation failure occurs. The problem is not in the allocation failure in itself, but in the dependency that we have between the state in shared memory and the allocation attempt for this pgstats code path. -- Michael
В списке pgsql-hackers по дате отправления: