Re: failed NUMA pages inquiry status: Operation not permitted
| От | Tomas Vondra |
|---|---|
| Тема | Re: failed NUMA pages inquiry status: Operation not permitted |
| Дата | |
| Msg-id | f1af27db-4e59-4c6b-9d8c-6f667186563a@vondra.me обсуждение исходный текст |
| Ответ на | Re: failed NUMA pages inquiry status: Operation not permitted (Christoph Berg <myon@debian.org>) |
| Список | pgsql-hackers |
On 12/16/25 18:54, Christoph Berg wrote: > Re: Tomas Vondra >> 1) right after opening a connection, I get this >> >> test=# select numa_node, count(*) from pg_buffercache_numa group by 1; >> numa_node | count >> -----------+------- >> 0 | 290 >> -2 | 32478 > > Does that mean that the "touch all pages" logic is missing in some > code paths? > I did check and AFAICS we are touching the pages in pg_buffercache_numa. To make it even more confusing, I can no longer reproduce the behavior I reported yesterday. It just consistently reports "0" and I have no idea why it changed :-( I did restart since yesterday, so maybe that changed something. > But even with that, it seems to be able to degenerate again and > accepting -2 in the regression tests would be required to make it > stable. > No opinion yet. Either the -2 can happen occasionally, and then we'd need to adjust the regression tests. Or maybe it's some thinko, and then it'd be good to figure out why it's happening. I find it interesting it does not seem to fail on the buildfarm. Or at least I'm not aware of such failures. Even a rare failure should show itself on the buildfarm a couple times, so how come it didn't? regards -- Tomas Vondra
В списке pgsql-hackers по дате отправления: