On Fri, 2010-07-09 at 17:21 -0400, Tom Lane wrote:
> Simon Riggs <si...@2ndquadrant.com> writes:
> > On Fri, 2010-07-09 at 14:01 -0400, Tom Lane wrote:
> >> Consider PREPARE followed only later by EXECUTE. Your proposal would
> >> make the PREPARE fail outright, when it currently does not.
>
> > Just to avoid wasted investigation: are you saying that is important
> > behaviour that is essential we retain in PostgreSQL, or will you hear
> > evidence that supporting that leads to a performance decrease elsewhere?
>
> Well, I think that that problem makes moving the checks into the planner
> a nonstarter. But as somebody pointed out upthread, you could still get
> what you want by keeping a flag saying "permission checks have been
> done" so the executor could skip the checks on executions after the
> first.
Seems like best idea.
> I'd still want to see some evidence showing that it's worth
> troubling over though. Premature optimization being the root of all
> evil, and all that. (In this case, the hazard we expose ourselves to
> seems to be security holes due to missed resets of the flag.)
If we did this it would be to add one line to the code
if (!perms_ok)
That doesn't seem to fall into the category of evil optimization to me.
I've seen you recode other parts of the executor stating reasons like
"shave another few cycles off the main path" and that seems the case
here. We shouldn't need to debate the consequences of Amhdahls law each
time.
Attached is a script to allow pgbench to be used to measure difference
between superuser and a typical privilege model for the pgbench tables.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and Services
drop user if exists ref;
create user ref;
drop user if exists cust;
create user cust;
drop user if exists report;
create user report;
drop user if exists xact;
create user xact;
/* Reference data */
GRANT INSERT, UPDATE, DELETE ON pgbench_tellers TO ref;
GRANT INSERT, UPDATE, DELETE ON pgbench_branches TO ref;
/* Customer maintenance */
GRANT INSERT, DELETE ON pgbench_accounts TO cust;
GRANT UPDATE (bid, filler) ON pgbench_accounts TO cust;
/* Reporting */
GRANT SELECT ON pgbench_accounts TO report;
GRANT SELECT ON pgbench_branches TO report;
GRANT SELECT ON pgbench_tellers TO report;
GRANT SELECT ON pgbench_history TO report;
/* Transactions */
GRANT UPDATE (abalance) ON pgbench_accounts TO xact;
GRANT UPDATE (tbalance) ON pgbench_tellers TO xact;
GRANT UPDATE (bbalance) ON pgbench_branches TO xact;
GRANT INSERT ON pgbench_history TO xact;
GRANT SELECT ON pgbench_accounts TO xact;
GRANT SELECT ON pgbench_branches TO xact;
GRANT SELECT ON pgbench_tellers TO xact;
GRANT SELECT ON pgbench_history TO xact;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
