Re: [HACKERS] Atomics for heap_parallelscan_nextpage()
От | Heikki Linnakangas |
---|---|
Тема | Re: [HACKERS] Atomics for heap_parallelscan_nextpage() |
Дата | |
Msg-id | 7e0a73a5-0df9-1859-b8ae-9acf122dc38d@iki.fi обсуждение исходный текст |
Ответ на | Re: [HACKERS] Atomics for heap_parallelscan_nextpage() (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [HACKERS] Atomics for heap_parallelscan_nextpage()
Re: [HACKERS] Atomics for heap_parallelscan_nextpage() Re: [HACKERS] Atomics for heap_parallelscan_nextpage() |
Список | pgsql-hackers |
On 08/16/2017 08:10 PM, Andres Freund wrote: >> Afaict shm_create/shm_toc_allocate don't actually guarantee that the end >> of the toc's memory is suitably aligned. But I didn't yet have any >> coffee, so ... > > Robert, I'm not quite sure what the intended behaviour of shm_toc is wrt > alignment. I see that individual chunks are BUFFERALIGNed (both during > estimation, and allocation). But I don't see how the size of the entire > toc is aligned, which seems a requirement, given we allocate from the > end. > Seems like we'd just have to add alignment of the total size to > shm_toc_estimate()? Yeah, that's the gist of it. The attached patch seems to fix this. I'm not too familiar with this DSM stuff, but this seems right to me. Unless someone has a better idea soon, I'll commit this to make the buildfarm happy. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: