From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: WIP: Faster Expression Processing v4
Date: Thu, 16 Mar 2017 11:15:16 -0400
Message-ID: <10634.1489677316@sss.pgh.pa.us> (raw)
In-Reply-To: <20170316004720.76oqddhtvsk6noqp@alap3.anarazel.de>
References: <20161206034955.bh33paeralxbtluv@alap3.anarazel.de>
<20170209003312.rr7atqepgbrf4xqe@alap3.anarazel.de>
<20170307030137.lpo4japv5oqgbqpz@alap3.anarazel.de>
<2090fd00-4dec-7b42-f700-64308958504c@2ndquadrant.com>
<20170313080351.4g5oubxcj4xj5y7t@alap3.anarazel.de>
<fcdaa51b-e905-72e0-39dd-5e22f535a253@2ndquadrant.com>
<20170314065259.ffef4tfhgbsaieoe@alap3.anarazel.de>
<69b7bb0e-8dab-3d39-1a89-3c6ab6409f64@iki.fi>
<20170314224706.nxvtapenky6eom3z@alap3.anarazel.de>
<13062.1489622943@sss.pgh.pa.us>
<20170316004720.76oqddhtvsk6noqp@alap3.anarazel.de>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Andres Freund <andres@anarazel.de> writes:
> On 2017-03-15 20:09:03 -0400, Tom Lane wrote:
>> That scares me quite a bit, because it smells exactly like the sort of
>> premature optimization that bit us on the rear in CVE-2016-5423 (cf commit
>> f0c7b789a).
> I don't think there's a danger similar to f0c7b789a here, because the
> "caller" (i.e. the node that needs the expression's result) expects
> resvalue/null to be overwritten.
Yeah, that's what I thought when I wrote the broken code in ExecEvalCase,
too. It was wrong. Basically you've got to be sure that no aliasing
can occur, and I think the only way to be safe about that is to have a
very clear rule about where results are allowed to get returned to,
preferably one that doesn't ever re-use the same target. (I think the
repeated use of the same subexpression result address for the arms of
an AND or OR is okay, but it would be a good idea to have a clear
statement of why.)
The thing that actually made the ExecEvalCase code into a bug was that
we were using ExprContext-level fields to store the current caseValue,
allowing aliasing to occur across nested CASEs. I think that in
this implementation, it ought to be possible to get rid of
ExprContext.caseValue_datum et al altogether, in favor of some storage
location that's private to each CASE expression. I'm a bit disappointed
that that doesn't seem to have happened.
Eventually, I would also like to find a way to remove the restriction
imposed by the other part of f0c7b789a, ie that we can't inline a SQL
function when that would result in intermixing two levels of CASE
expression. An implementation along the lines of what I've sketched
above could handle that easily enough, as long as we could identify
which nested level of CASE a particular CaseTestExpr belongs to.
I don't know how to do that offhand, but it seems like it ought to be
soluble if we put a bit of thought into it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, hlinnaka@iki.fi, tomas.vondra@2ndquadrant.com
Subject: Re: WIP: Faster Expression Processing v4
In-Reply-To: <10634.1489677316@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox