Re: Lock conflict behavior?
От | Bruce Momjian |
---|---|
Тема | Re: Lock conflict behavior? |
Дата | |
Msg-id | 200901212239.n0LMdhZ00710@momjian.us обсуждение исходный текст |
Ответ на | Re: Lock conflict behavior? (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: Lock conflict behavior?
|
Список | pgsql-hackers |
Jeff Davis wrote: > 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. Is this a TODO? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: