Re: Lock conflict behavior?

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Lock conflict behavior?
Дата
Msg-id 1230057282.5854.46.camel@dell.linuxdev.us.dell.com
обсуждение исходный текст
Ответ на Re: Lock conflict behavior?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Lock conflict behavior?  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On Tue, 2008-12-23 at 08:48 -0500, Tom Lane wrote:
> I've always thought that it was extremely shaky for LOCK to try to work
> that way.  With no lock, you have no confidence that the table isn't
> changing or disappearing under you.  In the worst case, the permissions
> check might fail outright (likely with a "cache lookup failed" message
> about a catalog row that disappeared as we attempted to fetch it); or it
> might give an answer that's obsolete by the time we do acquire the lock.

It looks like it would be easy enough to throw a better error message
than that, e.g. with a try/catch. The information could be obsolete, but
if it succeeds, it would at least mean they had permissions at some time
in the past.

Or, we could just remove the ACL checks from LOCK TABLE, so that it's at
least consistent. Mostly it's the inconsistency that bothers me.

Regards,Jeff Davis



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

Предыдущее
От: "Lawrence, Ramon"
Дата:
Сообщение: Re: Proposed Patch to Improve Performance of Multi-BatchHash Join for Skewed Data Sets
Следующее
От: Joshua Tolley
Дата:
Сообщение: Re: Proposed Patch to Improve Performance of Multi-Batch Hash Join for Skewed Data Sets