Horton

Re: RangeVarGetRelid()

Noah Misch <noah@leadboat.com>

View thread
From: Noah Misch <noah@leadboat.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Alvaro Herrera <alvherre@commandprompt.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2011-12-16T15:32:39Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Try to acquire relation locks in RangeVarGetRelid.

Attachments

On Thu, Dec 15, 2011 at 07:04:20PM -0500, Robert Haas wrote:
> On Fri, Dec 9, 2011 at 5:41 PM, Noah Misch <noah@leadboat.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.

To illustrate what I had in mind, here's a version of your patch that has five
callers sharing a callback.  The patch is against d039fd51f79e, just prior to
your recent commits.