pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix corruption of pgstats shared hashtable due to OOM failures 5+ messages / 1 participants [nested] [flat]
* pgsql: Fix corruption of pgstats shared hashtable due to OOM failures @ 2025-09-08 06:53 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 5+ messages in thread From: Michael Paquier @ 2025-09-08 06:53 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix corruption of pgstats shared hashtable due to OOM failures A new pgstats entry is created as a two-step process: - The entry is looked at in the shared hashtable of pgstats, and is inserted if not found. - When not found and inserted, its fields are then initialized. This part include a DSA chunk allocation for the stats data of the new entry. As currently coded, if the DSA chunk allocation fails due to an out-of-memory failure, an ERROR is generated, leaving in the pgstats shared hashtable an inconsistent entry due to the first step, as the entry has already been inserted in the hashtable. These broken entries can then be found by other backends, crashing them. There are only two callers of pgstat_init_entry(), when loading the pgstats file at startup and when creating a new pgstats entry. This commit changes pgstat_init_entry() so as we use dsa_allocate_extended() with DSA_ALLOC_NO_OOM, making it return NULL on allocation failure instead of failing. This way, a backend failing an entry creation can take appropriate cleanup actions in the shared hashtable before throwing an error. Currently, this means removing the entry from the shared hashtable before throwing the error for the allocation failure. Out-of-memory errors unlikely happen in the wild, and we do not bother with back-patches when these are fixed, usually. However, the problem dealt with here is a degree worse as it breaks the shared memory state of pgstats, impacting other processes that may look at an inconsistent entry that a different process has failed to create. Author: Mikhail Kot <mikhail.kot@databricks.com> Discussion: https://postgr.es/m/CAAi9E7jELo5_-sBENftnc2E8XhW2PKZJWfTC3i2y-GMQd2bcqQ@mail.gmail.com Backpatch-through: 15 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/12f57681c79bd3e8283bfb223dadba0efbe0b37e Modified Files -------------- src/backend/utils/activity/pgstat.c | 10 ++++++++++ src/backend/utils/activity/pgstat_shmem.c | 28 +++++++++++++++++++++++++++- 2 files changed, 37 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Fix corruption of pgstats shared hashtable due to OOM failures @ 2025-09-08 06:53 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 5+ messages in thread From: Michael Paquier @ 2025-09-08 06:53 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix corruption of pgstats shared hashtable due to OOM failures A new pgstats entry is created as a two-step process: - The entry is looked at in the shared hashtable of pgstats, and is inserted if not found. - When not found and inserted, its fields are then initialized. This part include a DSA chunk allocation for the stats data of the new entry. As currently coded, if the DSA chunk allocation fails due to an out-of-memory failure, an ERROR is generated, leaving in the pgstats shared hashtable an inconsistent entry due to the first step, as the entry has already been inserted in the hashtable. These broken entries can then be found by other backends, crashing them. There are only two callers of pgstat_init_entry(), when loading the pgstats file at startup and when creating a new pgstats entry. This commit changes pgstat_init_entry() so as we use dsa_allocate_extended() with DSA_ALLOC_NO_OOM, making it return NULL on allocation failure instead of failing. This way, a backend failing an entry creation can take appropriate cleanup actions in the shared hashtable before throwing an error. Currently, this means removing the entry from the shared hashtable before throwing the error for the allocation failure. Out-of-memory errors unlikely happen in the wild, and we do not bother with back-patches when these are fixed, usually. However, the problem dealt with here is a degree worse as it breaks the shared memory state of pgstats, impacting other processes that may look at an inconsistent entry that a different process has failed to create. Author: Mikhail Kot <mikhail.kot@databricks.com> Discussion: https://postgr.es/m/CAAi9E7jELo5_-sBENftnc2E8XhW2PKZJWfTC3i2y-GMQd2bcqQ@mail.gmail.com Backpatch-through: 15 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/8191e0c16a0373f851a9f5a8112e3aec105b5276 Modified Files -------------- src/backend/utils/activity/pgstat.c | 11 +++++++++++ src/backend/utils/activity/pgstat_shmem.c | 28 +++++++++++++++++++++++++++- 2 files changed, 38 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Fix corruption of pgstats shared hashtable due to OOM failures @ 2025-09-08 06:53 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 5+ messages in thread From: Michael Paquier @ 2025-09-08 06:53 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix corruption of pgstats shared hashtable due to OOM failures A new pgstats entry is created as a two-step process: - The entry is looked at in the shared hashtable of pgstats, and is inserted if not found. - When not found and inserted, its fields are then initialized. This part include a DSA chunk allocation for the stats data of the new entry. As currently coded, if the DSA chunk allocation fails due to an out-of-memory failure, an ERROR is generated, leaving in the pgstats shared hashtable an inconsistent entry due to the first step, as the entry has already been inserted in the hashtable. These broken entries can then be found by other backends, crashing them. There are only two callers of pgstat_init_entry(), when loading the pgstats file at startup and when creating a new pgstats entry. This commit changes pgstat_init_entry() so as we use dsa_allocate_extended() with DSA_ALLOC_NO_OOM, making it return NULL on allocation failure instead of failing. This way, a backend failing an entry creation can take appropriate cleanup actions in the shared hashtable before throwing an error. Currently, this means removing the entry from the shared hashtable before throwing the error for the allocation failure. Out-of-memory errors unlikely happen in the wild, and we do not bother with back-patches when these are fixed, usually. However, the problem dealt with here is a degree worse as it breaks the shared memory state of pgstats, impacting other processes that may look at an inconsistent entry that a different process has failed to create. Author: Mikhail Kot <mikhail.kot@databricks.com> Discussion: https://postgr.es/m/CAAi9E7jELo5_-sBENftnc2E8XhW2PKZJWfTC3i2y-GMQd2bcqQ@mail.gmail.com Backpatch-through: 15 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/1852ec5db5d8e1c16a39a307fde853d6a7cfa8aa Modified Files -------------- src/backend/utils/activity/pgstat.c | 10 ++++++++++ src/backend/utils/activity/pgstat_shmem.c | 28 +++++++++++++++++++++++++++- 2 files changed, 37 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Fix corruption of pgstats shared hashtable due to OOM failures @ 2025-09-08 06:53 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 5+ messages in thread From: Michael Paquier @ 2025-09-08 06:53 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix corruption of pgstats shared hashtable due to OOM failures A new pgstats entry is created as a two-step process: - The entry is looked at in the shared hashtable of pgstats, and is inserted if not found. - When not found and inserted, its fields are then initialized. This part include a DSA chunk allocation for the stats data of the new entry. As currently coded, if the DSA chunk allocation fails due to an out-of-memory failure, an ERROR is generated, leaving in the pgstats shared hashtable an inconsistent entry due to the first step, as the entry has already been inserted in the hashtable. These broken entries can then be found by other backends, crashing them. There are only two callers of pgstat_init_entry(), when loading the pgstats file at startup and when creating a new pgstats entry. This commit changes pgstat_init_entry() so as we use dsa_allocate_extended() with DSA_ALLOC_NO_OOM, making it return NULL on allocation failure instead of failing. This way, a backend failing an entry creation can take appropriate cleanup actions in the shared hashtable before throwing an error. Currently, this means removing the entry from the shared hashtable before throwing the error for the allocation failure. Out-of-memory errors unlikely happen in the wild, and we do not bother with back-patches when these are fixed, usually. However, the problem dealt with here is a degree worse as it breaks the shared memory state of pgstats, impacting other processes that may look at an inconsistent entry that a different process has failed to create. Author: Mikhail Kot <mikhail.kot@databricks.com> Discussion: https://postgr.es/m/CAAi9E7jELo5_-sBENftnc2E8XhW2PKZJWfTC3i2y-GMQd2bcqQ@mail.gmail.com Backpatch-through: 15 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/3e6dfcfb0529a9d003e07a56f58d0ff3c46556bf Modified Files -------------- src/backend/utils/activity/pgstat.c | 10 ++++++++++ src/backend/utils/activity/pgstat_shmem.c | 28 +++++++++++++++++++++++++++- 2 files changed, 37 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Fix corruption of pgstats shared hashtable due to OOM failures @ 2025-09-08 06:53 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 5+ messages in thread From: Michael Paquier @ 2025-09-08 06:53 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix corruption of pgstats shared hashtable due to OOM failures A new pgstats entry is created as a two-step process: - The entry is looked at in the shared hashtable of pgstats, and is inserted if not found. - When not found and inserted, its fields are then initialized. This part include a DSA chunk allocation for the stats data of the new entry. As currently coded, if the DSA chunk allocation fails due to an out-of-memory failure, an ERROR is generated, leaving in the pgstats shared hashtable an inconsistent entry due to the first step, as the entry has already been inserted in the hashtable. These broken entries can then be found by other backends, crashing them. There are only two callers of pgstat_init_entry(), when loading the pgstats file at startup and when creating a new pgstats entry. This commit changes pgstat_init_entry() so as we use dsa_allocate_extended() with DSA_ALLOC_NO_OOM, making it return NULL on allocation failure instead of failing. This way, a backend failing an entry creation can take appropriate cleanup actions in the shared hashtable before throwing an error. Currently, this means removing the entry from the shared hashtable before throwing the error for the allocation failure. Out-of-memory errors unlikely happen in the wild, and we do not bother with back-patches when these are fixed, usually. However, the problem dealt with here is a degree worse as it breaks the shared memory state of pgstats, impacting other processes that may look at an inconsistent entry that a different process has failed to create. Author: Mikhail Kot <mikhail.kot@databricks.com> Discussion: https://postgr.es/m/CAAi9E7jELo5_-sBENftnc2E8XhW2PKZJWfTC3i2y-GMQd2bcqQ@mail.gmail.com Backpatch-through: 15 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/f256a7bba7286058bbf9d5ce160e3237dfe83b79 Modified Files -------------- src/backend/utils/activity/pgstat.c | 11 +++++++++++ src/backend/utils/activity/pgstat_shmem.c | 28 +++++++++++++++++++++++++++- 2 files changed, 38 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2025-09-08 06:53 UTC | newest] Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-09-08 06:53 pgsql: Fix corruption of pgstats shared hashtable due to OOM failures Michael Paquier <michael@paquier.xyz> 2025-09-08 06:53 pgsql: Fix corruption of pgstats shared hashtable due to OOM failures Michael Paquier <michael@paquier.xyz> 2025-09-08 06:53 pgsql: Fix corruption of pgstats shared hashtable due to OOM failures Michael Paquier <michael@paquier.xyz> 2025-09-08 06:53 pgsql: Fix corruption of pgstats shared hashtable due to OOM failures Michael Paquier <michael@paquier.xyz> 2025-09-08 06:53 pgsql: Fix corruption of pgstats shared hashtable due to OOM failures Michael Paquier <michael@paquier.xyz>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox