Re: SQL/JSON: functions

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: a(dot)kozhemyakin(at)postgrespro(dot)ru
Cc: Greg Stark <stark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Nikola Ivanov <kolioffx(at)gmail(dot)com>, Himanshu Upadhyaya <upadhyaya(dot)himanshu(at)gmail(dot)com>, Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, PostgreSQL-development <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Oleg Bartunov <obartunov(at)postgrespro(dot)ru>, Erik Rijkers <er(at)xs4all(dot)nl>
Subject: Re: SQL/JSON: functions
Date: 2022-07-07 18:35:00
Message-ID: 5dcfde92-8ba9-a202-483b-35c0ca484c1c@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2022-07-07 Th 12:38, a(dot)kozhemyakin(at)postgrespro(dot)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(at)entry=0x563cc55a3c40,
> count=count(at)entry=9223372036854775807,
> isTopLevel=isTopLevel(at)entry=true, run_once=run_once(at)entry=true,
> dest=dest(at)entry=0x563cc5602758, altdest=altdest(at)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(at)entry=3,
> argv=argv(at)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2022-07-07 18:38:44 Re: pg15b2: large objects lost on upgrade
Previous Message Bruce Momjian 2022-07-07 18:24:04 Re: pg15b2: large objects lost on upgrade