Re: [HACKERS] Atomics for heap_parallelscan_nextpage()

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Atomics for heap_parallelscan_nextpage()
Дата
Msg-id 32056.1502906432@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Atomics for heap_parallelscan_nextpage()  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] Atomics for heap_parallelscan_nextpage()  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Aug 16, 2017 at 1:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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 Heikki also patched shm_toc_estimate.  With the
> patch, if the size being used in shm_toc_create comes from
> shm_toc_estimate, it will always be aligned and nothing bad will
> happen.

Sure.  So the point is entirely about what should happen if someone
doesn't use shm_toc_estimate.

> If the user invents another size out of whole cloth, then
> they might get a few bytes less than they expect, but that's what you
> get for not using shm_toc_estimate().

I don't buy that argument.  A caller might think "Why do I need
shm_toc_estimate, when I can compute the *exact* size I need?".
And it would have worked, up till this proposed patch.

I think the new API spec for such cases ought to be "if you supply an
unaligned size, we'll error out", not "if you supply an unaligned size,
we'll silently lose some of it".  The former is going to behave a lot
more predictably.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Atomics for heap_parallelscan_nextpage()
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] 10 beta docs: different replication solutions