Hi Tom,
On Monday, July 9, 2018 7:41:59 PM CEST Tom Lane wrote:
> Pavel Raiskup <praiskup@redhat.com> writes:
> > while I tried to debug 'gcc -fstack-protector -O3' problems in [1], I noticed
> > that gbt_var_union() mistreats the first vector element. Patch is attached.
>
> 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...)
I've been looking at the reproducer for a while now... and I probably
need a hint if that's necessary.
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.
Considering testcase 'bit.sql' (bit(33) type), it's pretty clear that on
little endian boxes the problematic strings would be '00100001*' (int32
value for '33', because there's varbit header). Big endian boxes would
have problems with char[] like {0, 0, 0, 33, ...}. But I fail to
construct right order of correctly picked elements into 'bit.data'.
The problem probably is (a) that picksplit reorders the elements very
often, and probably that (b) random() brings non-determinism into the
final tree shape (if the reproducer was to be based on many equal keys in
the index). It's amazing to see how the index fixes itself :-) for this
bug.
Can you help me with the reproducer idea, resp. can we live without the
reproducer in this particular case?
Pavel
