Re: [HACKERS] Atomics for heap_parallelscan_nextpage() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Atomics for heap_parallelscan_nextpage()
Date
Msg-id 32056.1502906432@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Atomics for heap_parallelscan_nextpage()  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] Atomics for heap_parallelscan_nextpage()  (Heikki Linnakangas <hlinnaka@iki.fi>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] Atomics for heap_parallelscan_nextpage()
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] 10 beta docs: different replication solutions