On 2/9/21 3:46 PM, John Naylor wrote:
On Wed, Feb 3, 2021 at 7:54 PM Tomas Vondra
<tomas.von...@enterprisedb.com <mailto:tomas.von...@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
