Re: Bitmap index scans use of filters on available columns

Hi,

On 11/05/2015 06:51 PM, Robert Haas wrote:
> On Wed, Nov 4, 2015 at 9:15 PM, Tomas Vondra
> <tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
>> I certainly understand there are cases that require care - like the
>> leakproof thing pointed out by Robert for example. I don't immediately see
>> why evaluation against dead rows would be a problem.
>
> Well, one thing is that you might leak information about
> already-deleted rows, which could be a security vulnerability, or more
> mundanely cause a function to error out when there are no actually
> visible rows that could trigger such an error. It would be surprising
> if you could add a CHECK(b != 0) constraint to a table, query it for
> rows where a/b>1, and get a division by zero error.

Yes, I guess we don't have this problem when evaluating the expression
on heap because we get to check visibility first, and after moving the
expression to the index we can't do that.

But then again, can we come up with a way to distinguish operators that
are safe to evaluate on indexes - either automatic or manual? We already
do that with the indexable operators with explicitly listing them in the
opclass, and we also explicitly use the LEAKPROOF for a similar thing. I
don't think extending the opclass is a really good solution, but why not
to invent another *PROOF flag?

> But I think it's even worse: I believe there can be dead rows in the
> heap whose tuple descriptor doesn't even match the current
> pg_attribute contents. Consider BEGIN; ALTER TABLE ... ADD COLUMN ...
> int8; INSERT ...; ROLLBACK; ALTER TABLE .. ADD COLUMN .. text; SELECT
> ... If the SELECT tries to decode one of the tuples added by the
> failed transaction considering the new column as text when the dead
> tuples in question had it as an int8, I suspect that you can crash the
> server. Nothing good will happen, anyway.

But that is about heap, and we're discussing indexes here, right? I
don't think you can break the index descriptor like this, because
otherwise we'd already have problems with that.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services