On 2/9/21 3:46 PM, John Naylor wrote:
> On Wed, Feb 3, 2021 at 7:54 PM Tomas Vondra
> <tomas.vondra@enterprisedb.com <mailto:tomas.vondra@enterprisedb.com>>
> wrote:
> >
> > [v-20210203]
>
> Hi Tomas,
>
> I have some random comments from reading the patch, but haven't gone
> into detail in the newer aspects. I'll do so in the near future.
>
> The cfbot seems to crash on this patch during make check, but it doesn't
> crash for me. I'm not even sure what date that cfbot status is from.
>
Yeah, I noticed that too, and I'm investigating.
I tried running the regression tests on a 32-bit machine (rpi4), which
sometimes uncovers strange failures, and that indeed fails. There are
two or three bugs.
Firstly, the allocation optimization patch does this:
MAXALIGN(sizeof(ScanKey) * scan->numberOfKeys * natts)
instead of
MAXALIGN(sizeof(ScanKey) * scan->numberOfKeys) * natts
and that sometimes produces the wrong result, triggering an assert.
Secondly, there seems to be an issue with cross-type bloom indexes.
Imagine you have an int8 column, with a bloom index on it, and then you
do this:
WHERE column = '122'::int4;
Currently, we end up passing this to the consistent function, which
tries to call hashint8 on the int4 datum - that succeeds on 64 bits
(because both types are byval), but fails on 32-bits (where int8 is
byref, so it fails on int4). Which causes a segfault.
I think I included those cross-type operators as a copy-paste from
minmax indexes, but I see hash indexes don't allow this. And removing
those cross-type rows from pg_amop.dat makes the crashes go away.
It's also possible I simplified the get_strategy_procinfo a bit too
much. I see the minmax variant has subtype, so maybe we could do this
instead (I recall the integer types should have "compatible" results).
There are a couple failues where the index does not produce the right
number of results, though. I haven't investigated that yet. Once I fix
this, I'll post an updated patch - hopefully that'll make cfbot happy.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company