Обсуждение: BUG #17215: ltree tests failing in REL_14_STABLE / commit cb8a5a588

The following bug has been logged on the website:

Bug reference:      17215
Logged by:          James Robinson
Email address:      james@jlr-photo.com
PostgreSQL version: 14.0
Operating system:   OSX
Description:

When running the contrib/ltree checks against a build on OSX 10.13 (yeah, I
know) against commit cb8a5a588e in REL_14_STABLE, am dying due to: 

#  SELECT * FROM ltreetest WHERE t =  '12.3' order by t asc;
ERROR:  unrecognized StrategyNumber: 6

PG Bug reporting form <noreply@postgresql.org> writes:
> When running the contrib/ltree checks against a build on OSX 10.13 (yeah, I
> know) against commit cb8a5a588e in REL_14_STABLE, am dying due to: 

> #  SELECT * FROM ltreetest WHERE t =  '12.3' order by t asc;
> ERROR:  unrecognized StrategyNumber: 6

Hm, the OSX members of the buildfarm aren't unhappy, and nobody else has
reported similar symptoms.  You might try a full rebuild (tear it
down with "git clean -dfx" and start over).

            regards, tom lane

On Tue, Oct 05, 2021 at 10:21:46PM +0000, PG Bug reporting form wrote:
> When running the contrib/ltree checks against a build on OSX 10.13 (yeah, I
> know) against commit cb8a5a588e in REL_14_STABLE, am dying due to:
>
> #  SELECT * FROM ltreetest WHERE t =  '12.3' order by t asc;
> ERROR:  unrecognized StrategyNumber: 6

Adding Peter and Heikki here.

That may look like a corruption, but by re-running the tests this is
reproducible, right?  Are you running a simple "make check"?  Perhaps
you forgot to clean up your source directory before recompiling?  Or
is that an installcheck on an existing instance, which has some
particular configuration not checked in the buildfarm?  This query
uses only BTEqualStrategyNumber here.  Now, it seems to me that this
could point to an actual bug, where the consistent function tries to
use a picksplit, but it should not in a certain code path.  I am not
really a gist expert, just saying, but there are diffs between 13 and
14 in this area.
--
Michael

> On Oct 5, 2021, at 10:14 PM, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Tue, Oct 05, 2021 at 10:21:46PM +0000, PG Bug reporting form wrote:
>> When running the contrib/ltree checks against a build on OSX 10.13 (yeah, I
>> know) against commit cb8a5a588e in REL_14_STABLE, am dying due to:
>>
>> #  SELECT * FROM ltreetest WHERE t =  '12.3' order by t asc;
>> ERROR:  unrecognized StrategyNumber: 6
>
> Adding Peter and Heikki here.
>
> That may look like a corruption, but by re-running the tests this is
> reproducible, right?  Are you running a simple "make check"?  Perhaps
> you forgot to clean up your source directory before recompiling?  Or
> is that an installcheck on an existing instance, which has some
> particular configuration not checked in the buildfarm?  This query
> uses only BTEqualStrategyNumber here.  Now, it seems to me that this
> could point to an actual bug, where the consistent function tries to
> use a picksplit, but it should not in a certain code path.  I am not
> really a gist expert, just saying, but there are diffs between 13 and
> 14 in this area.
> --
> Michael

I'm 'make distclean' and re-running configure between compilation runs. I've narrowed it down to the error being raised
withinltree_gist.c's ltree_consistent(). Moreover, as a total gross hack guess / attempt, if I augment the
switch(strategy)to handle RTSameStrategyNumber ( = 6 per stratnum.h) as equivalent to BTEqualStrategyNumber via an
additionalcase statement: 

--- a/contrib/ltree/ltree_gist.c
+++ b/contrib/ltree/ltree_gist.c
@@ -640,6 +640,7 @@ ltree_consistent(PG_FUNCTION_ARGS)
                        res = (ltree_compare((ltree *) query, LTG_GETLNODE(key, siglen)) >= 0);
                        break;
                case BTEqualStrategyNumber:
+               case RTSameStrategyNumber:
                        query = PG_GETARG_LTREE_P(1);
                        if (GIST_LEAF(entry))
                                res = (ltree_compare((ltree *) query, LTG_NODE(key)) == 0);


then 'make check' within contrib/ltree passes. Remove that added case, and it fails on what appears to be all of the
gistindexed ltree equality queries in the regression suite: 

diff -U3 /Users/jlrobins/pg-devel/git/contrib/ltree/expected/ltree.out
/Users/jlrobins/pg-devel/git/contrib/ltree/results/ltree.out
--- /Users/jlrobins/pg-devel/git/contrib/ltree/expected/ltree.out    2020-06-30 10:31:51.000000000 -0400
+++ /Users/jlrobins/pg-devel/git/contrib/ltree/results/ltree.out    2021-10-05 23:16:19.000000000 -0400
@@ -5899,11 +5899,7 @@
 (124 rows)

 SELECT * FROM ltreetest WHERE t =  '12.3' order by t asc;
-  t
-------
- 12.3
-(1 row)
-
+ERROR:  unrecognized StrategyNumber: 6
 SELECT * FROM ltreetest WHERE t >= '12.3' order by t asc;
                 t
 ----------------------------------
@@ -7839,11 +7835,7 @@
 (1 row)

 SELECT count(*) FROM ltreetest WHERE t =  '12.3';
- count
--------
-     1
-(1 row)
-
+ERROR:  unrecognized StrategyNumber: 6
 SELECT count(*) FROM ltreetest WHERE t >= '12.3';
  count
 -------

Can reproduce this using clang / llvm 11 and 12. Am cooking with:

./configure \
    --with-includes=/opt/local/include \
    --with-libraries=/opt/local/lib \
    --prefix=/Users/jlrobins/pg-devel \
    --with-llvm \
    --with-perl --with-python --with-tcl \
     -enable-nls --enable-cassert \
    --enable-debug --with-libxml --with-libxslt --with-openssl \
    --with-gssapi --enable-debug --with-icu

Could this 6 be coming from ltree--1.1.sql line 545:

CREATE OPERATOR CLASS gist_ltree_ops
    DEFAULT FOR TYPE ltree USING gist AS
  OPERATOR  1 < ,
  OPERATOR  2 <= ,
  OPERATOR  3 && ,
  OPERATOR  4 >= ,
  OPERATOR  5 > ,
  OPERATOR  6 = ,
...

?


-----
James Robinson
james@jlr-photo.com
http://jlr-photo.com/