Re: [COMMITTERS] pgsql: Add a hook in ExecCheckRTPerms(). - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: [COMMITTERS] pgsql: Add a hook in ExecCheckRTPerms().
Date
Msg-id 1278694308.29736.621.camel@ebony
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Add a hook in ExecCheckRTPerms().  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [COMMITTERS] pgsql: Add a hook in ExecCheckRTPerms().
List pgsql-hackers
On Fri, 2010-07-09 at 11:09 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > Strangely, I was looking into removing the ExecCheckRTPerms check
> > altogether by forcing plan invalidation when permissions are updated.
> > That would be a performance tweak that would render this change useless.
> 
> That seems both pointless and wrong.  Permissions checks should happen
> at execution time not plan time.

Agreed that permission checks should logically be applied at execution
time. I am proposing a performance optimisation, not a change in
behaviour.

Permissions are set much less frequently than plans and connections, so
when the only permission check is at table level it makes more sense to
optimistically assume that permission checks will never change for a
plan and cache the result of the permission check. That way we need only
check permissions once at plan time rather than checking them every
single execution.

The only extra code to do this would be to invalidate plans when
permissions change for a table. That doesn't seem hard or invasive.

The proposed performance enhancement would be very useful since we have
to check permissions of functions, views, tables and every other aspect.
We could spend a while quantifying that overhead, though "non-zero" is
all we need to know.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Development, 24x7 Support, Training and Services



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: [COMMITTERS] pgsql: Add a hook in ExecCheckRTPerms().
Next
From: Robert Haas
Date:
Subject: Re: ALTER TABLE SET STATISTICS requires AccessExclusiveLock