Re: Lock conflict behavior? - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Lock conflict behavior?
Date
Msg-id 1230057282.5854.46.camel@dell.linuxdev.us.dell.com
Whole thread Raw
In response to Re: Lock conflict behavior?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Lock conflict behavior?  (Bruce Momjian <bruce@momjian.us>)
List 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 by date:

Previous
From: "Lawrence, Ramon"
Date:
Subject: Re: Proposed Patch to Improve Performance of Multi-BatchHash Join for Skewed Data Sets
Next
From: Joshua Tolley
Date:
Subject: Re: Proposed Patch to Improve Performance of Multi-Batch Hash Join for Skewed Data Sets