Greetings, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Jun 8, 2022 at 5:55 PM Peter Geoghegan <p...@bowt.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
signature.asc
Description: PGP signature
