mirror of
https://github.com/postgres/postgres.git
synced 2026-04-25 08:08:08 -04:00
3fccbd94cb
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 |
||
|---|---|---|
| .. | ||
| expected | ||
| sql | ||
| .gitignore | ||
| Makefile | ||
| meson.build | ||
| pg_buffercache--1.0--1.1.sql | ||
| pg_buffercache--1.1--1.2.sql | ||
| pg_buffercache--1.2--1.3.sql | ||
| pg_buffercache--1.2.sql | ||
| pg_buffercache--1.3--1.4.sql | ||
| pg_buffercache--1.4--1.5.sql | ||
| pg_buffercache--1.5--1.6.sql | ||
| pg_buffercache--1.6--1.7.sql | ||
| pg_buffercache.control | ||
| pg_buffercache_pages.c | ||