Re: [PATCH] btree_gist: fix union implementation for variable length columns

From: Pavel Raiskup <praiskup(at)redhat(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Teodor Sigaev <teodor(at)sigaev(dot)ru>
Subject: Re: [PATCH] btree_gist: fix union implementation for variable length columns
Date: 2018-07-11 18:24:59
Message-ID: 4076084.lpus4j4ZWx@nb.usersys.redhat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wednesday, July 11, 2018 7:26:40 PM CEST Tom Lane wrote:
> Pavel Raiskup <praiskup(at)redhat(dot)com> writes:
> > On Monday, July 9, 2018 7:41:59 PM CEST Tom Lane wrote:
> >> Hi Pavel! For patches that purport to resolve bugs, we usually like to
> >> add a regression test case that demonstrates the bug in unpatched code.
> >> Can you provide a small test case that does so? (The BZ you pointed to
> >> doesn't seem to address this...)
>
> > Turns out the problem is only related to bit/bit varying type (so the
> > patch comments need to be reworded properly, at least) since those are the
> > only types which have implemented the f_l2n() callback.
>
> What I'm failing to wrap my head around is why this code exists at all.
> AFAICS, gbt_bit_xfrm just forces the bitstring to be zero-padded out to
> an INTALIGN boundary, which it wouldn't necessarily be otherwise.
> But why bother? That should have no effect on the behavior of bit_cmp().

The gbt_bit_xfrm() method actually also skips the varbit header (number of
bits, stored in VarBit.bit_len), the magic is done by VARBITS macro. If
the header is dropped, it's OK to just use existing byteacmp() for bit
array comparison.

Pavel

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Asim R P 2018-07-11 18:31:22 Re: Shared buffer access rule violations?
Previous Message Alvaro Herrera 2018-07-11 18:04:17 Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors