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