From: | Mike Palmiotto <mike(dot)palmiotto(at)crunchydata(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Joe Conway <mail(at)joeconway(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, fte(at)nct(dot)ru, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org>, Amit Langote <amitlangote09(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: BUG #14682: row level security not work with partitioned table |
Date: | 2017-06-07 18:11:19 |
Message-ID: | CAMN686G317mGcd62yfjvEPyqFpt1UgPZX7USM7Ci0pFiZp6FTA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On Wed, Jun 7, 2017 at 9:49 AM, Mike Palmiotto
<mike(dot)palmiotto(at)crunchydata(dot)com> wrote:
> One thing that concerns me is the first EXPLAIN plan from regress_rls_dave:
> +EXPLAIN (COSTS OFF) SELECT * FROM part_document WHERE f_leak(dtitle);
> + QUERY PLAN
> +----------------------------------------------------------------------------------------------------
> + Append
> + InitPlan 1 (returns $0)
> + -> Index Scan using uaccount_pkey on uaccount
> + Index Cond: (pguser = CURRENT_USER)
> + -> Seq Scan on part_document_fiction
> + Filter: ((cid <> 55) AND (cid <> 55) AND (cid < 99) AND
> (dlevel <= $0) AND f_leak(dtitle))
> + -> Seq Scan on part_document_satire
> + Filter: ((cid <> 55) AND (cid <> 55) AND (cid < 99) AND
> (dlevel <= $0) AND f_leak(dtitle))
> +(8 rows)
>
> I would expect that both part_document_satire (cid == 55) and
> part_document_nonfiction (cid == 99) would be excluded from the
> explain, but only cid < 99 seems to work. Interestingly, when I change
> policy pp1r to cid < 55, I see the following:
>
> +EXPLAIN (COSTS OFF) SELECT * FROM part_document WHERE f_leak(dtitle);
> + QUERY PLAN
> +---------------------------------------------------------------------------------------------------
> + Append
> + InitPlan 1 (returns $0)
> + -> Index Scan using uaccount_pkey on uaccount
> + Index Cond: (pguser = CURRENT_USER)
> + -> Seq Scan on part_document_fiction
> + Filter: ((cid < 55) AND (cid <> 55) AND (cid < 99) AND
> (dlevel <= $0) AND f_leak(dtitle))
> +(6 rows)
>
> Is this a demonstration of a non-immutable function backing the
> operator and thus not being able to filter it from the planner, or is
> it a bug?
Assuming my digging is correct, there's some other explanation for
this not working as expected...
postgres=> select po.oprname, pp.proname, pp.provolatile from pg_proc
pp join pg_operator po on pp.proname::text = po.oprcode::text where
po.oprname = '<>' and pp.proname like 'int%ne';
oprname | proname | provolatile
---------+-------------+-------------
<> | int4ne | i
<> | int2ne | i
<> | int24ne | i
<> | int42ne | i
<> | int8ne | i
<> | int84ne | i
<> | int48ne | i
<> | interval_ne | i
<> | int28ne | i
<> | int82ne | i
(10 rows)
Thoughts?
Thanks,
--
Mike Palmiotto
Software Engineer
Crunchy Data Solutions
https://crunchydata.com
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-06-08 00:07:40 | Re: [PATCH] Fixed malformed error message on malformed SCRAM message. |
Previous Message | Pavel Stehule | 2017-06-07 16:39:00 | Re: BUG #14694: Long binded parameter value in the postgres log |
From | Date | Subject | |
---|---|---|---|
Next Message | Fabrízio de Royes Mello | 2017-06-07 18:29:28 | Re: Directory pg_replslot is not properly cleaned |
Previous Message | Kevin Grittner | 2017-06-07 18:10:27 | Re: Re: [GSOC 17] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions |