From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: RangeVarGetRelid() |
Date: | 2011-12-16 00:04:20 |
Message-ID: | CA+TgmoZ4APGRjX5WOfSBn2moR09Xnh_bL7CLbVcEu_Ds95sxPw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Dec 9, 2011 at 5:41 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> It also seems my last explanation didn't convey the point. Yes, nearly every
> command has a different set of permissions checks. However, we don't benefit
> equally from performing each of those checks before acquiring a lock.
> Consider renameatt(), which checks three things: you must own the relation,
> the relation must be of a supported relkind, and the relation must not be a
> typed table. To limit opportunities for denial of service, let's definitely
> perform the ownership check before taking a lock. The other two checks can
> wait until we hold that lock. The benefit of checking them early is to avoid
> making a careless relation owner wait for a lock before discovering the
> invalidity of his command. That's nice as far as it goes, but let's not
> proliferate callbacks for such a third-order benefit.
I agree, but my point is that so far we have no callbacks that differ
only in that detail. I accept that we'd probably want to avoid that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Kupershmidt | 2011-12-16 00:36:10 | Re: Patch to allow users to kill their own queries |
Previous Message | Simon Riggs | 2011-12-15 23:42:07 | Re: Moving more work outside WALInsertLock |