Re: SQL/JSON: functions

On 2022-07-07 Th 12:38, a.kozhemyakin@postgrespro.ru wrote:
> Hello hackers,
> On branch REL_15_STABLE the following query: SELECT
> JSON_SERIALIZE('{"a":1}' RETURNING jsonb);
>
> produces SIGSEGV for me:
> #0  getJsonbOffset (index=39920251, jc=0x563cc5601d5c) at
> jsonb_util.c:148
> 148                     offset += JBE_OFFLENFLD(jc->children[i]);
> (gdb) bt
> #0  getJsonbOffset (index=39920251, jc=0x563cc5601d5c) at
> jsonb_util.c:148
> #1  JsonbIteratorNext (it=0x7ffdaff752c8, val=0x7ffdaff752d0,
> skipNested=false) at jsonb_util.c:933
> #2  0x0000563cc3e6934b in JsonbToCStringWorker (out=0x563cc55fe9a0,
> in=<optimized out>, estimated_len=<optimized out>, indent=false) at
> jsonb.c:496
> #3  0x0000563cc3f35c68 in FunctionCall1Coll (arg1=<optimized out>,
> collation=0, flinfo=0x563cc55fb8a0) at fmgr.c:1124
> #4  OutputFunctionCall (flinfo=0x563cc55fb8a0, val=<optimized out>) at
> fmgr.c:1561
> #5  0x0000563cc3a8ebc5 in printtup (slot=0x563cc55faed8,
> self=0x563cc5602758) at printtup.c:357
> #6  0x0000563cc3c51917 in ExecutePlan (execute_once=<optimized out>,
> dest=0x563cc5602758, direction=<optimized out>, numberTuples=0,
> sendTuples=<optimized out>, operation=CMD_SELECT,
> use_parallel_mode=<optimized out>, planstate=0x563cc55fabb8,
>     estate=0x563cc55fa980) at execMain.c:1667
> #7  standard_ExecutorRun (queryDesc=0x563cc5553e60,
> direction=<optimized out>, count=0, execute_once=<optimized out>) at
> execMain.c:363
> #8  0x0000563cc3df741f in PortalRunSelect (portal=0x563cc55a3c40,
> forward=<optimized out>, count=0, dest=<optimized out>) at pquery.c:924
> #9  0x0000563cc3df8b81 in PortalRun
> (portal=portal@entry=0x563cc55a3c40,
> count=count@entry=9223372036854775807,
> isTopLevel=isTopLevel@entry=true, run_once=run_once@entry=true,
> dest=dest@entry=0x563cc5602758, altdest=altdest@entry=0x563cc5602758,
>     qc=0x7ffdaff75650) at pquery.c:768
> #10 0x0000563cc3df498d in exec_simple_query
> (query_string=0x563cc5531f00 "SELECT JSON_SERIALIZE('{\"a\":1}'
> RETURNING jsonb);") at postgres.c:1250
> #11 0x0000563cc3df651a in PostgresMain (dbname=<optimized out>,
> username=<optimized out>) at postgres.c:4558
> #12 0x0000563cc3d5b5e7 in BackendRun (port=<optimized out>,
> port=<optimized out>) at postmaster.c:4504
> #13 BackendStartup (port=<optimized out>) at postmaster.c:4232
> #14 ServerLoop () at postmaster.c:1806
> #15 0x0000563cc3d5c6da in PostmasterMain (argc=argc@entry=3,
> argv=argv@entry=0x563cc552c6d0) at postmaster.c:1478
> #16 0x0000563cc3a7b550 in main (argc=3, argv=0x563cc552c6d0) at
> main.c:202
>
> The first bad commit is 606948b058dc16bce494270eea577011a602810e



Thanks for the report. Looking into it.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com