Re: [sqlsmith] Crash in mcv_get_match_bitmap
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Andreas Seltenreich <seltenreich@gmx.de>,
pgsql-hackers@lists.postgresql.org,
Tomas Vondra <tomas.vondra@postgresql.org>
Date: 2019-07-18T15:16:08Z
Lists: pgsql-hackers
Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> I've pushed the fixes listed in the previous message, with the exception
> of the collation part, because I had some doubts about that.
Sorry for being slow on this.
> Now, for the collation part - after some more thought and looking at code
> I think the fix I shared before is OK. It uses per-column collations
> consistently both when building the stats and estimating clauses, which
> makes it consistent. I was not quite sure if using Var->varcollid is the
> same thing as pg_attribute.attcollation, but it seems it is - at least for
> Vars pointing to regular columns (which for extended stats should always
> be the case).
I think you are right, but it could use some comments in the code.
The important point here is that if we coerce a Var's collation to
something else, that will be represented as a separate CollateExpr
(which will be a RelabelType by the time it gets here, I believe).
We don't just replace varcollid, the way eval_const_expressions will
do to a Const.
While I'm looking at the code --- I don't find this at all convincing:
/*
* We don't care about isgt in equality, because
* it does not matter whether it's (var op const)
* or (const op var).
*/
match = DatumGetBool(FunctionCall2Coll(&opproc,
DEFAULT_COLLATION_OID,
cst->constvalue,
item->values[idx]));
It *will* matter if the operator is cross-type. I think there is no
good reason to have different code paths for the equality and inequality
cases --- just look at isgt and swap or don't swap the arguments.
BTW, "isgt" seems like a completely misleading name for that variable.
AFAICS, what that is actually telling is whether the var is on the left
or right side of the OpExpr. Everywhere else in the planner with a
need for that uses "bool varonleft", and I think you should do likewise
here (though note that that isgt, as coded, is more like "varonright").
regards, tom lane
Commits
-
Use column collation for extended statistics
- a63378a03ec0 13.0 landed
- 5a8ee9f2dbe0 12.0 landed
-
Rework examine_opclause_expression to use varonleft
- e38a55ba46bb 13.0 landed
- fc4faea17971 12.0 landed
-
Fix handling of NULLs in MCV items and constants
- 1c2acc32dc6c 12.0 landed
- e4deae7396f2 13.0 landed
-
Fix handling of opclauses in extended statistics
- 42276976a143 12.0 landed
- e8b6ae2130e3 13.0 landed
-
Remove unnecessary TYPECACHE_GT_OPR lookup
- 3944e855bc5b 12.0 landed
- a4303a078c66 13.0 landed
-
Simplify bitmap updates in multivariate MCV code
- 79d3a1e52a3c 12.0 landed
- 7d24f6a49076 13.0 landed
-
Make pg_statistic and related code account more honestly for collations.
- 5e09280057a4 12.0 cited