Re: RangeVarGetRelid()

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: RangeVarGetRelid()
Дата
Msg-id CA+TgmoZ4APGRjX5WOfSBn2moR09Xnh_bL7CLbVcEu_Ds95sxPw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: RangeVarGetRelid()  (Noah Misch <noah@leadboat.com>)
Ответы Re: RangeVarGetRelid()  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Moving more work outside WALInsertLock
Следующее
От: Josh Kupershmidt
Дата:
Сообщение: Re: Patch to allow users to kill their own queries