Re: BTMaxItemSize seems to be subtly incorrect - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: BTMaxItemSize seems to be subtly incorrect
Date
Msg-id CAH2-Wznh0mpBYs12OD_GANaCYGg3dLYruavp917TL2W9c5AP8Q@mail.gmail.com
Whole thread Raw
In response to Re: BTMaxItemSize seems to be subtly incorrect  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: BTMaxItemSize seems to be subtly incorrect
List pgsql-hackers
On Thu, Aug 4, 2022 at 10:40 PM Peter Geoghegan <pg@bowt.ie> wrote:
> This very likely has something to do with the way nbtdedup.c uses
> BTMaxItemSize(), which apparently won't work on these 32-bit systems
> now.

Update: I discovered that I can get the regression tests to fail (even
on mainstream 64-bit platforms) by MAXALIGN()'ing the expression that
we assign to state->maxpostingsize at the top of _bt_dedup_pass().
This is surprising; it contradicts existing comments that explain that
the existing max is 1/6 of a page by choice, to get better space
utilization than the more natural cap of 1/3 of a page. It now looks
like that might have actually been strictly necessary, all along.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: pgsql: BRIN: mask BRIN_EVACUATE_PAGE for WAL consistency checking
Next
From: Alvaro Herrera
Date:
Subject: Re: annoyance with .git-blame-ignore-revs