From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | James Coleman <jtc331(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: sqlsmith crash incremental sort |
Date: | 2020-04-11 22:44:45 |
Message-ID: | 20200411224445.x4whiaeo67glpqen@development |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
I've looked into this a bit, and at first I thought that maybe the issue
is in how cost_incremental_sort picks the EC members. It simply does this:
EquivalenceMember *member = (EquivalenceMember *)
linitial(key->pk_eclass->ec_members);
so I was speculating that maybe there are multiple EC members and the
one we need is not the first one. That would have been easy to fix.
But that doesn't seem to be the case - in this example the EC ony has a
single EC member anyway.
(gdb) p key->pk_eclass->ec_members
$14 = (List *) 0x12eb958
(gdb) p *key->pk_eclass->ec_members
$15 = {type = T_List, length = 1, max_length = 5, elements = 0x12eb970, initial_elements = 0x12eb970}
and the member is a Var with varno=0 (with a RelabelType on top, but
that's irrelevant).
(gdb) p *(Var*)((RelabelType*)member->em_expr)->arg
$12 = {xpr = {type = T_Var}, varno = 0, varattno = 1, vartype = 12445, vartypmod = -1, varcollid = 950, varlevelsup = 0, varnosyn = 0, varattnosyn = 1, location = -1}
which then triggers the assert in find_base_rel. When looking for other
places calling estimate_num_groups I found this in prepunion.c:
* XXX you don't really want to know about this: we do the estimation
* using the subquery's original targetlist expressions, not the
* subroot->processed_tlist which might seem more appropriate. The
* reason is that if the subquery is itself a setop, it may return a
* processed_tlist containing "varno 0" Vars generated by
* generate_append_tlist, and those would confuse estimate_num_groups
* mightily. We ought to get rid of the "varno 0" hack, but that
* requires a redesign of the parsetree representation of setops, so
* that there can be an RTE corresponding to each setop's output.
which seems pretty similar to the issue at hand, because the subpath is
T_UpperUniquePath (not sure if that passes as setop, but the symptoms
match nicely).
Not sure what to do about it in cost_incremental_sort, though :-(
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2020-04-11 23:08:17 | Re: pg_basebackup, manifests and backends older than ~12 |
Previous Message | Justin Pryzby | 2020-04-11 22:33:19 | Re: pg_stat_statements issue with parallel maintenance (Was Re: WAL usage calculation patch) |