On Mon, Oct 22, 2018 at 7:40 PM David Fetter <da...@fetter.org> wrote: > > On Mon, Oct 22, 2018 at 04:43:52PM +0530, Dilip Kumar wrote: > > On Mon, Oct 22, 2018 at 11:22 AM David Fetter <da...@fetter.org> wrote: > > > > > > On Mon, Oct 22, 2018 at 11:10:09AM +0530, Dilip Kumar wrote: > > > > As part of the security fix > > > > (e2d4ef8de869c57e3bf270a30c12d48c2ce4e00c), we have restricted the > > > > users from accessing the statistics of the table if the user doesn't > > > > have privileges on the table and the function is not leakproof. > > > > Now, as a side effect of this, if the user has the privileges on the > > > > root partitioned table but does not have privilege on the child > > > > tables, the user will be able to access the data of the child table > > > > but it won't be able to access the statistics of the child table. > > > > > > Do we have any kind of quantitative idea of how much worse query > > > performance gets with this blind spot? > > > > One of our customers reported the issue where they have executed the > > same query by granting privileges only on the base table vs granting > > privileges on all the partitions. The execution time was more than 2 > > hours in the first case whereas it got completed in 10 seconds in the > > second case. > > That's just awful. Were permissions set correctly per their threat > model, as far as you can tell?
AFAIU, they are having a root table with around 300 child partitions so they just granted the permission on the main table considering that should be enough and ended up in the bad plan. > Was the query constructed correctly? > Am I understanding correctly that the query as constructed spanned one > or more partitions that the role querying didn't have permission to > see? The query spanned over more than 200 partitions but the role has permission only on the root table, considering that should be enough to access child partitions. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
