I do see two assertions in spgtextproc.c fail on occasion when testing
with sqlsmith:
TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 424)
TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 564)
I can't reproduce it reliably but looking at the coredumps, the failing
part of the expression is always
in->level == 0 && DatumGetPointer(in->reconstructedValue) == NULL
In all of the dumps I looked at, in->reconstructedValue contains a
zero-length text instead of the asserted NULL, and the tuples fed to
leaf_consistent()/inner_consistent() look like the one below.
,----
| (gdb) p *in
| $1 = {scankeys = 0x60a3ee0, nkeys = 1, reconstructedValue = 101373680, level
= 0,
| returnData = 1 '\001', allTheSame = 1 '\001', hasPrefix = 0 '\000',
prefixDatum = 0, nNodes = 8,
| nodeLabels = 0x37b6768}
| (gdb) x ((text *)in->reconstructedValue)->vl_len_
| 0x60ad6f0: 0x00000010
| (gdb) p *(text *)in->scankeys[0]->sk_argument
| $2 = {vl_len_ = "0\000\000", vl_dat = 0x855950c "sqlsmith~", '\177' <repeats
8123 times>, "\020 "}
| (gdb) p in->nodeLabels[0]
| $3 = 65535
`----
Maybe these assertions are just too strict? I don't see the code
misbehaving when relaxing them to
reconstrValue != NULL && VARSIZE_ANY_EXHDR(reconstrValue) == in->level
|| in->level == 0
regards,
Andreas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
