pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Handle ENOENT status when querying NUMA node 2+ messages / 1 participants [nested] [flat]
* pgsql: Handle ENOENT status when querying NUMA node @ 2026-01-26 23:22 Tomas Vondra <tomas.vondra@postgresql.org> 0 siblings, 0 replies; 2+ messages in thread From: Tomas Vondra @ 2026-01-26 23:22 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Handle ENOENT status when querying NUMA node We've assumed that touching the memory is sufficient for a page to be located on one of the NUMA nodes. But a page may be moved to a swap after we touch it, due to memory pressure. We touch the memory before querying the status, but there is no guarantee it won't be moved to the swap in the meantime. The touching happens only on the first call, so later calls are more likely to be affected. And the batching increases the window too. It's up to the kernel if/when pages get moved to swap. We have to accept ENOENT (-2) as a valid result, and handle it without failing. This patch simply treats it as an unknown node, and returns NULL in the two affected views (pg_shmem_allocations_numa and pg_buffercache_numa). Hugepages cannot be swapped out, so this affects only regular pages. Reported by Christoph Berg, investigation and fix by me. Backpatch to 18, where the two views were introduced. Reported-by: Christoph Berg <myon@debian.org> Discussion: 18 Backpatch-through: https://postgr.es/m/aTq5Gt_n-oS_QSpL@msg.df7cb.de Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/3fccbd94cba0e4ee7a28d22eb5eb64b9fa23f234 Modified Files -------------- contrib/pg_buffercache/pg_buffercache_pages.c | 12 ++++++++-- src/backend/storage/ipc/shmem.c | 32 +++++++++++++++++++++------ 2 files changed, 35 insertions(+), 9 deletions(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
* pgsql: Handle ENOENT status when querying NUMA node @ 2026-01-26 23:22 Tomas Vondra <tomas.vondra@postgresql.org> 0 siblings, 0 replies; 2+ messages in thread From: Tomas Vondra @ 2026-01-26 23:22 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Handle ENOENT status when querying NUMA node We've assumed that touching the memory is sufficient for a page to be located on one of the NUMA nodes. But a page may be moved to a swap after we touch it, due to memory pressure. We touch the memory before querying the status, but there is no guarantee it won't be moved to the swap in the meantime. The touching happens only on the first call, so later calls are more likely to be affected. And the batching increases the window too. It's up to the kernel if/when pages get moved to swap. We have to accept ENOENT (-2) as a valid result, and handle it without failing. This patch simply treats it as an unknown node, and returns NULL in the two affected views (pg_shmem_allocations_numa and pg_buffercache_numa). Hugepages cannot be swapped out, so this affects only regular pages. Reported by Christoph Berg, investigation and fix by me. Backpatch to 18, where the two views were introduced. Reported-by: Christoph Berg <myon@debian.org> Discussion: 18 Backpatch-through: https://postgr.es/m/aTq5Gt_n-oS_QSpL@msg.df7cb.de Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/9796c4f5607be5807f2d2ba9bca1bc87af198db3 Modified Files -------------- contrib/pg_buffercache/pg_buffercache_pages.c | 12 ++++++++-- src/backend/storage/ipc/shmem.c | 32 +++++++++++++++++++++------ 2 files changed, 35 insertions(+), 9 deletions(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-01-26 23:22 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-01-26 23:22 pgsql: Handle ENOENT status when querying NUMA node Tomas Vondra <tomas.vondra@postgresql.org> 2026-01-26 23:22 pgsql: Handle ENOENT status when querying NUMA node Tomas Vondra <tomas.vondra@postgresql.org>
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