From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: BTMaxItemSize seems to be subtly incorrect |
Date: | 2022-06-09 18:47:31 |
Message-ID: | 20220609184731.GO9030@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greetings,
* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> 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 had seen something along these lines when also playing with trying to
use special space. I hadn't had a chance to run down exactly where it
was coming from, so thanks for working on this.
> > 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.
Agreed that it doesn't seem like we'd need to backpatch this.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2022-06-09 18:47:42 | Re: Checking for missing heap/index files |
Previous Message | Bruce Momjian | 2022-06-09 18:46:02 | Re: Checking for missing heap/index files |