On Fri, Aug 5, 2022 at 10:13 AM Peter Geoghegan wrote:
> 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().
Looks like this was nothing
On Thu, Aug 4, 2022 at 10:40 PM Peter Geoghegan 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
On Thu, Aug 4, 2022 at 10:25 PM Thomas Munro wrote:
> FYI florican and lapwing showed:
>
> 2022-08-05 01:04:29.903 EDT [34485:5] FATAL: deduplication failed to
> add heap tid to pending posting list
> 2022-08-05 01:04:29.903 EDT [34485:6] CONTEXT: WAL redo at 0/49708D8
> for Btree/DEDUP:
On Fri, Aug 5, 2022 at 3:56 PM Peter Geoghegan wrote:
> On Thu, Jun 9, 2022 at 11:20 AM Robert Haas wrote:
> > I think I'd feel more comfortable if you wrote the patch, if that's
> > possible.
>
> Okay, pushed a fix just now.
FYI florican and lapwing showed:
2022-08-05 01:04:29.903 EDT
On Thu, Jun 9, 2022 at 11:20 AM Robert Haas wrote:
> I think I'd feel more comfortable if you wrote the patch, if that's possible.
Okay, pushed a fix just now.
Thanks
--
Peter Geoghegan
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jun 8, 2022 at 5:55 PM Peter Geoghegan 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
On Thu, Jun 9, 2022 at 1:39 PM Peter Geoghegan wrote:
> On Thu, Jun 9, 2022 at 6:40 AM Robert Haas wrote:
> > Are you going to code up a patch?
>
> I can, but feel free to fix it yourself if you prefer. Your analysis
> seems sound.
I think I'd feel more comfortable if you wrote the patch, if
On Thu, Jun 9, 2022 at 6:40 AM Robert Haas wrote:
> Are you going to code up a patch?
I can, but feel free to fix it yourself if you prefer. Your analysis
seems sound.
--
Peter Geoghegan
On Wed, Jun 8, 2022 at 7:44 PM Peter Geoghegan wrote:
> FWIW I don't see much difference between borrowing special space and
> adding something to BTPageOpaqueData. If anything I'd prefer the
> latter.
I think this discussion will take us too far afield from the topic of
this thread, so I'll
On Wed, Jun 8, 2022 at 4:18 PM Robert Haas wrote:
> 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
On Wed, Jun 8, 2022 at 5:55 PM Peter Geoghegan 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
On Wed, Jun 8, 2022 at 2:23 PM Robert Haas wrote:
> In my tests, PageGetPageSize(page) = 8192, SizeOfPageHeaderData = 24,
> sizeof(ItemIdData) = 4, sizeof(ItemPointerData) = 6, and
> sizeof(BTPageOpaqueData) = 16. Assuming MAXIMUM_ALIGNOF == 8, I
> believe that makes BTMaxItemSize come out to
We have these two definitions in the source code:
#define BTMaxItemSize(page) \
MAXALIGN_DOWN((PageGetPageSize(page) - \
MAXALIGN(SizeOfPageHeaderData + \
3*sizeof(ItemIdData) + \
3*sizeof(ItemPointerData)) - \
13 matches
Mail list logo
