Re: SELECT with COLLATE results in segfault on trunk and 12 Beta 2

Hi everyone,

the following statements also result in a segfault on the current
trunk (in toast_raw_datum_size()):

CREATE TABLE t0(c0 TEXT, c1 TEXT, PRIMARY KEY(c0, c1));
CREATE TABLE t1(c0 TEXT, c1 TEXT, FOREIGN KEY (c0, c1) REFERENCES t0(c0, c1));
CREATE STATISTICS s0 ON c0, c1 FROM t0;
INSERT INTO t0(c1, c0) VALUES('a', 'a'), ('b', 'a'), ('c', 'a'), ('d',
'a'), ('e', 'a'), ('f', 'a');
ANALYZE;
UPDATE t0 SET c0 = 'b';

This segfault seems to be related to the previous one that I reported,
since it also happens in texteq(), although in a different function:

#0 0x0000560ac2a82e90 in toast_raw_datum_size ()
#1 0x0000560ac2e264f8 in texteq ()
#2 0x0000560ac2e4e5ca in FunctionCall2Coll ()
#3 0x0000560ac2cf4e3c in mcv_get_match_bitmap ()
#4 0x0000560ac2cf71a1 in mcv_clauselist_selectivity ()
#5 0x0000560ac2cf36a4 in statext_clauselist_selectivity ()
#6 0x0000560ac2c523bb in clauselist_selectivity ()
#7 0x0000560ac2c583ed in set_baserel_size_estimates ()
#8 0x0000560ac2c4fb90 in set_rel_size ()
#9 0x0000560ac2c51580 in make_one_rel ()

For these statements, the data changed by the UPDATE is lost.

Would you consider this bug to be distinct, or is it the same as the
previous one that I reported?

I could not reproduce this on the latest release version, so I assume
again that this is not a security issue.

Best,
Manuel

On Mon, Jul 15, 2019 at 12:22 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Manuel Rigger <rigger(dot)manuel(at)gmail(dot)com> writes:
> > When executing the statements below, Postgres crashes:
>
> > CREATE TABLE t0(c0 BOOLEAN, c1 TEXT);
> > CREATE STATISTICS s1 ON c0, c1 FROM t0;
> > INSERT INTO t0(c0) VALUES (FALSE);
> > VACUUM ANALYZE t0;
> > SELECT * FROM t0 WHERE t0.c0 OR '' >= t0.c1 COLLATE "C"; -- unexpected: segfault
>
> Backtrace shows
>
> #0 pg_detoast_datum_packed (datum=0x7f7f7f7f7f7f7f7f) at fmgr.c:1773
> #1 0x00000000008a9b90 in text_ge (fcinfo=0x7ffc8cdbfd40) at varlena.c:1859
> #2 0x00000000008cf307 in FunctionCall2Coll (flinfo=0x7ffc8cdbfe00,
> collation=<value optimized out>, arg1=<value optimized out>,
> arg2=<value optimized out>) at fmgr.c:1162
> #3 0x0000000000773db0 in mcv_get_match_bitmap (root=0x26b7bc8,
> clauses=<value optimized out>, keys=0x26b8b90, mcvlist=0x26b88f0,
> is_or=true) at mcv.c:1661
> #4 0x0000000000773ecb in mcv_get_match_bitmap (root=0x26b7bc8,
> clauses=<value optimized out>, keys=0x26b8b90, mcvlist=0x26b88f0,
> is_or=false) at mcv.c:1744
> #5 0x0000000000775d61 in mcv_clauselist_selectivity (root=0x26b7bc8,
> stat=0x26b8b58, clauses=0x26b9008, varRelid=<value optimized out>,
> jointype=<value optimized out>, sjinfo=<value optimized out>,
> rel=0x25a46a0, basesel=0x7ffc8cdc0038, totalsel=0x7ffc8cdc0030)
> at mcv.c:1876
>
> I think this is another variant of the mcv_get_match_bitmap
> issues that you and Andreas already reported, ie, that code isn't
> expecting to find anything but a bare Var or Const, so the
> CollateExpr node above the Var confuses it.
>
> It's possible that it'd be worth descending through CollateExpr
> nodes in the same way as for RelabelType nodes, and for more or
> less the same reason.
>
> regards, tom lane