pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Justin Pryzby <pryzby@telsasoft.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: Amit Langote <amitlangote09@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: vignesh C <vignesh21@gmail.com>
Cc: pgsql-hackers@postgresql.org
Cc: e.indrupskaya@postgrespro.ru
Subject: Re: SQL/JSON revisited
Date: Mon, 27 Mar 2023 16:18:41 -0500
Message-ID: <ZCIIMVyD4MKjJrNG@telsasoft.com> (raw)
In-Reply-To: <20230327185456.wbb5gchworsu3hf7@alvherre.pgsql>
References: <20230322121846.vcxjogqyguihkicr@alvherre.pgsql>
	<20230327185456.wbb5gchworsu3hf7@alvherre.pgsql>

I ran sqlsmith on this patch for a short while, and reduced one of its
appalling queries to this:

postgres=# SELECT jsonb_object_agg_unique_strict('', null::xid8);
ERROR:  unexpected jsonb type as object key

postgres=# \errverbose 
ERROR:  XX000: unexpected jsonb type as object key
UBICACIÓN:  JsonbIteratorNext, jsonb_util.c:958

As you know, it's considered bad if elog()s are reachable, user-facing errors.

2023-03-27 15:46:47.351 CDT client backend[13361] psql ERROR:  unexpected jsonb type as object key
2023-03-27 15:46:47.351 CDT client backend[13361] psql BACKTRACE:  
        postgres: pryzbyj postgres [local] SELECT(JsonbIteratorNext+0x1e5) [0x5638fa11ba82]
        postgres: pryzbyj postgres [local] SELECT(+0x4ff951) [0x5638fa114951]
        postgres: pryzbyj postgres [local] SELECT(JsonbToCString+0x12) [0x5638fa116584]
        postgres: pryzbyj postgres [local] SELECT(jsonb_out+0x24) [0x5638fa1165ad]
        postgres: pryzbyj postgres [local] SELECT(FunctionCall1Coll+0x51) [0x5638fa1ef585]
        postgres: pryzbyj postgres [local] SELECT(OutputFunctionCall+0x15) [0x5638fa1f067d]
        postgres: pryzbyj postgres [local] SELECT(+0xe7ef7) [0x5638f9cfcef7]
        postgres: pryzbyj postgres [local] SELECT(+0x2b4271) [0x5638f9ec9271]
        postgres: pryzbyj postgres [local] SELECT(standard_ExecutorRun+0x146) [0x5638f9ec9402]

What might indicate a worse problem is that with debug_discard_caches=1, it
does something different:

postgres=# \errverbose 
ERROR:  XX000: invalid jsonb scalar type
UBICACIÓN:  convertJsonbScalar, jsonb_util.c:1865

2023-03-27 15:51:21.788 CDT client backend[15939] psql ERROR:  invalid jsonb scalar type
2023-03-27 15:51:21.788 CDT client backend[15939] psql CONTEXT:  parallel worker
2023-03-27 15:51:21.788 CDT client backend[15939] psql BACKTRACE:  
        postgres: pryzbyj postgres [local] SELECT(ThrowErrorData+0x2a6) [0x5638fa1ec8f3]
        postgres: pryzbyj postgres [local] SELECT(+0x194820) [0x5638f9da9820]
        postgres: pryzbyj postgres [local] SELECT(HandleParallelMessages+0x15d) [0x5638f9daac95]
        postgres: pryzbyj postgres [local] SELECT(ProcessInterrupts+0x906) [0x5638fa094873]
        postgres: pryzbyj postgres [local] SELECT(+0x2d202b) [0x5638f9ee702b]
        postgres: pryzbyj postgres [local] SELECT(+0x2d2206) [0x5638f9ee7206]
        postgres: pryzbyj postgres [local] SELECT(+0x2d245a) [0x5638f9ee745a]
        postgres: pryzbyj postgres [local] SELECT(+0x2bbcec) [0x5638f9ed0cec]
        postgres: pryzbyj postgres [local] SELECT(+0x2b4240) [0x5638f9ec9240]
        postgres: pryzbyj postgres [local] SELECT(standard_ExecutorRun+0x146) [0x5638f9ec9402]

+valgrind indicates this:

==14095== Use of uninitialised value of size 8
==14095==    at 0x60D1C9: convertJsonbScalar (jsonb_util.c:1822)
==14095==    by 0x60D44F: convertJsonbObject (jsonb_util.c:1741)
==14095==    by 0x60D630: convertJsonbValue (jsonb_util.c:1611)
==14095==    by 0x60D903: convertToJsonb (jsonb_util.c:1565)
==14095==    by 0x60F272: JsonbValueToJsonb (jsonb_util.c:117)
==14095==    by 0x60A504: jsonb_object_agg_finalfn (jsonb.c:2057)
==14095==    by 0x3D0806: finalize_aggregate (nodeAgg.c:1119)
==14095==    by 0x3D2210: finalize_aggregates (nodeAgg.c:1353)
==14095==    by 0x3D2E7F: agg_retrieve_direct (nodeAgg.c:2512)
==14095==    by 0x3D32DC: ExecAgg (nodeAgg.c:2172)
==14095==    by 0x3C3CEB: ExecProcNodeFirst (execProcnode.c:464)
==14095==    by 0x3BC23F: ExecProcNode (executor.h:272)
==14095==    by 0x3BC23F: ExecutePlan (execMain.c:1633)

And then it shows a different error:
2023-03-27 16:00:10.072 CDT standalone backend[14095] ERROR:  unknown type of jsonb container to convert

In the docs:

+        The <parameter>key</parameter> can not be null. If the
+        <parameter>value</parameter> is null then the entry is skipped,

s/can not/cannot/
The "," is dangling.

-- 
Justin





view thread (46+ messages)  latest in thread

Message-ID: <ZCIIMVyD4MKjJrNG@telsasoft.com>
Permalink:  ../ZCIIMVyD4MKjJrNG@telsasoft.com/
Also on:    postgresql.org/message-id/ZCIIMVyD4MKjJrNG@telsasoft.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: pryzby@telsasoft.com, alvherre@alvh.no-ip.org, andrew@dunslane.net, amitlangote09@gmail.com, peter.eisentraut@enterprisedb.com, andres@anarazel.de, vignesh21@gmail.com, e.indrupskaya@postgrespro.ru
  Subject: Re: SQL/JSON revisited
  In-Reply-To: <ZCIIMVyD4MKjJrNG@telsasoft.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox