Re: [HACKERS] Atomics for heap_parallelscan_nextpage()
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] Atomics for heap_parallelscan_nextpage() |
Дата | |
Msg-id | 20170816174858.tiyaw7qm7qhzrk2w@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] Atomics for heap_parallelscan_nextpage() (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 2017-08-16 13:44:28 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > Don't think we require BUFFERALIGN - MAXALIGN ought to be > > sufficient. > > Uh, see my other message just now. Yup, you're right. > > The use of BUFFERALIGN presumably is to space out things > > into different cachelines, but that doesn't really seem to be important > > with this. Then we can just avoid defining the new macro... > > I was feeling a bit uncomfortable with the BUFFERALIGN_DOWN() for a > different reason: if the caller has specified the exact amount of space it > needs, having shm_toc_create discard some could lead to an unexpected > failure. Well, that's why shm_toc_estimate() increases the size appropriately. > I wonder whether maybe shm_toc_create should just error out if the > number it's handed isn't aligned already. I think that's going to be harder atm, because it's not the size shm_toc computes, it's what the caller to shm_toc_estimate_chunk() provides. And that size is already guaranteed to be upsized by BUFFERALIGN in shm_toc_estimate_chunk(). It's just that the base-offset from where the allocations start isn't aligned. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: