Noah Misch <n...@leadboat.com> writes: > I can reproduce the 4 MiB allocations described > in https://postgr.es/m/29823.1525132...@sss.pgh.pa.us; a few times per > "vcregress check", they emerge in the middle of PGSharedMemoryReAttach(). > The 4 MiB allocations are stacks for new threads of the default thread > pool[1].
Hah! It is great to finally have an understanding of what is happening here. I worry that your proposed fix is unstable, in particular this assumption seems shaky: > + * ... The idea is that, if the allocator handed out > + * REGION1 pages before REGION2 pages at one occasion, it will do so whenever > + * both regions are free. I wonder whether it's possible to address this by configuring the "default thread pool" to have only one thread? It seems like the extra threads are just adding backend startup overhead to no benefit, since we won't use 'em. regards, tom lane