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
