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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Atomics for heap_parallelscan_nextpage()
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Atomics for heap_parallelscan_nextpage()