Re: BTMaxItemSize seems to be subtly incorrect

On Wed, Jun 8, 2022 at 5:55 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> > That's a problem, because if in that scenario you allow three 2704
> > byte items that don't need a heap TID and later you find you need to
> > add a heap TID to one of those items, the result will be bigger than
> > 2704 bytes, and then you can't fit three of them into a page.
>
> Seems you must be right. I'm guessing that the field "cabbage" was
> originally a nonce value, as part of a draft patch you're working on?

I wasn't originally setting out to modify BTPageOpaqueData at all,
just borrow some special space. See the "storing an explicit nonce"
discussion and patch set. But when this regression failure turned up I
said to myself, hmm, I think this is an unrelated bug.

> I think that we should fix this on HEAD, on general principle. There
> is no reason to believe that this is a live bug, so a backpatch seems
> unnecessary.

Yeah, I agree with not back-patching the fix, unless it turns out that
there is some platform where the same issue occurs without any
cabbage. I assume that if it happened on any common system someone
would have complained about it by now, so probably it doesn't. I
suppose we could try to enumerate plausibly different values of the
quantities involved and see if any of the combinations look like they
lead to a bad result. I'm not really sure how many things could
plausibly be different, though, apart from MAXIMUM_ALIGNOF.

--
Robert Haas
EDB: http://www.enterprisedb.com