Horton

Thread

Commits

  1. Fix overly strict Assert in jsonpath code

  1. BUG #18035: Assertion failure in jsonb_path_query

    The Post Office <noreply@postgresql.org> — 2023-07-25T08:57:58Z

    The following bug has been logged on the website:

Bug reference:      18035
Logged by:          Alexander Kozhemyakin
Email address:      a.kozhemyakin@postgrespro.ru
PostgreSQL version: 16beta2
Operating system:   Ubuntu 22.04
Description:        

Hello,
On REL_16_BETA2 the following query: select jsonb_path_query('{}', '($[0]
like_regex "").type()');
produces assert for me: 
#0  __pthread_kill_implementation (no_tid=0, signo=6,
threadid=140056864479808) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=140056864479808) at
./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=140056864479808, signo=signo@entry=6) at
./nptl/pthread_kill.c:89
#3  0x00007f618a283476 in __GI_raise (sig=sig@entry=6) at
../sysdeps/posix/raise.c:26
#4  0x00007f618a2697f3 in __GI_abort () at ./stdlib/abort.c:79
#5  0x0000561da5cc266f in ExceptionalCondition (
    conditionName=conditionName@entry=0x561da5e70778 "v->type == jpiString
|| v->type == jpiNumeric || v->type == jpiBool || v->type == jpiNull ||
v->type == jpiKey || v->type == jpiAny || v->type == jpiAnyArray || v->type
== jpiAnyKey || v->type == jpiI"..., fileName=fileName@entry=0x561da5e70ccc
"jsonpath.c", lineNumber=lineNumber@entry=977) at assert.c:66
#6  0x0000561da5c0a4bb in jspGetNext (v=v@entry=0x7ffc228330e0,
a=a@entry=0x7ffc22833020) at jsonpath.c:977
#7  0x0000561da5c0be3d in appendBoolResult (res=jpbUnknown,
found=0x7ffc22833190, jsp=0x7ffc228330e0, cxt=0x7ffc22833110) at
jsonpath_exec.c:2067
#8  executeItemOptUnwrapTarget (cxt=0x7ffc22833110, jsp=0x7ffc228330e0,
jb=0x7ffc228330c0, found=0x7ffc22833190, unwrap=<optimized out>) at
jsonpath_exec.c:641
#9  0x0000561da5c0d5e1 in executeItem (found=0x7ffc22833190,
jb=0x7ffc228330c0, jsp=0x7ffc228330e0, cxt=0x7ffc22833110) at
jsonpath_exec.c:603
#10 executeJsonPath (path=0x561da77fc6b0, vars=0x561da77fc740,
json=0x561da77fc698, throwErrors=<optimized out>, result=0x7ffc22833190,
useTz=<optimized out>) at jsonpath_exec.c:589
#11 0x0000561da5c0dc44 in jsonb_path_query_internal (fcinfo=0x561da78b4298,
tz=<optimized out>) at jsonpath_exec.c:420
#12 0x0000561da59c7466 in ExecMakeFunctionResultSet (fcache=0x561da78aec70,
econtext=econtext@entry=0x561da78ae270, argContext=0x561da78b5e60,
isNull=0x561da78aec00, isDone=isDone@entry=0x561da78aec58) at
execSRF.c:625
#13 0x0000561da59f130f in ExecProjectSRF (node=node@entry=0x561da78ae160,
continuing=continuing@entry=false) at nodeProjectSet.c:175
#14 0x0000561da59f13ec in ExecProjectSet (pstate=0x561da78ae160) at
nodeProjectSet.c:105
#15 0x0000561da59bdb8a in ExecProcNode (node=0x561da78ae160) at
../../../src/include/executor/executor.h:273
#16 ExecutePlan (execute_once=<optimized out>, dest=0x561da78a92e8,
direction=<optimized out>, numberTuples=0, sendTuples=true,
operation=CMD_SELECT, use_parallel_mode=<optimized out>,
planstate=0x561da78ae160, estate=0x561da78adf38) at execMain.c:1670
#17 standard_ExecutorRun (queryDesc=0x561da7756318, direction=<optimized
out>, count=0, execute_once=<optimized out>) at execMain.c:365
#18 0x0000561da5b845df in PortalRunSelect (portal=0x561da784e548,
forward=<optimized out>, count=0, dest=<optimized out>) at pquery.c:924
#19 0x0000561da5b85ca0 in PortalRun (portal=portal@entry=0x561da784e548,
count=count@entry=9223372036854775807, isTopLevel=isTopLevel@entry=true,
run_once=run_once@entry=true, dest=dest@entry=0x561da78a92e8,
altdest=altdest@entry=0x561da78a92e8,
    qc=0x7ffc22833570) at pquery.c:768
#20 0x0000561da5b81bb6 in exec_simple_query (query_string=0x561da77d40d8
"select jsonb_path_query('{}', '($[0] like_regex \"\").type()');") at
postgres.c:1274
#21 0x0000561da5b83355 in PostgresMain (dbname=<optimized out>,
username=<optimized out>) at postgres.c:4632
#22 0x0000561da5aea970 in BackendRun (port=0x561da77ff580) at
postmaster.c:4461
#23 BackendStartup (port=0x561da77ff580) at postmaster.c:4189
#24 ServerLoop () at postmaster.c:1779
#25 0x0000561da5aebb83 in PostmasterMain (argc=argc@entry=3,
argv=argv@entry=0x561da773fbf0) at postmaster.c:1463
#26 0x0000561da57ed4ee in main (argc=3, argv=0x561da773fbf0) at main.c:198

  2. Re: BUG #18035: Assertion failure in jsonb_path_query

    David Rowley <dgrowleyml@gmail.com> — 2023-07-25T14:55:51Z

    On Tue, 25 Jul 2023 at 22:01, PG Bug reporting form
<noreply@postgresql.org> wrote:
> On REL_16_BETA2 the following query: select jsonb_path_query('{}', '($[0]
> like_regex "").type()');
> produces assert for me:

I'm no json path expert, but from what I can tell, this Assert is just
missing a condition for jpiLikeRegex.

With that added, it seems to properly determine that the regex test
returns boolean.

postgres=# select jsonb_path_query($$["string", "string"]$$, '($[0]
like_regex ".{5}")');
 jsonb_path_query
------------------
 true
(1 row)


postgres=# select jsonb_path_query($$["string", "string"]$$, '($[0]
like_regex ".{7}")');
 jsonb_path_query
------------------
 false
(1 row)


postgres=# select jsonb_path_query($$["string", "string"]$$, '($[0]
like_regex ".{7}").type()');
 jsonb_path_query
------------------
 "boolean"
(1 row)

The only other enum value missing from that Assert is jpiSubscript.

David

  3. Re: BUG #18035: Assertion failure in jsonb_path_query

    David Rowley <dgrowleyml@gmail.com> — 2023-08-01T13:46:19Z

    On Wed, 26 Jul 2023 at 02:55, David Rowley <dgrowleyml@gmail.com> wrote:
>
> On Tue, 25 Jul 2023 at 22:01, PG Bug reporting form
> <noreply@postgresql.org> wrote:
> > On REL_16_BETA2 the following query: select jsonb_path_query('{}', '($[0]
> > like_regex "").type()');
> > produces assert for me:
>
> I'm no json path expert, but from what I can tell, this Assert is just
> missing a condition for jpiLikeRegex.
>
> With that added, it seems to properly determine that the regex test
> returns boolean.

I've now pushed the patch to fix the Assert.

David