From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Lock conflict behavior? |
Date: | 2008-12-23 18:34:41 |
Message-ID: | 1230057282.5854.46.camel@dell.linuxdev.us.dell.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2008-12-23 18:42:48 | Re: Synchronous replication, network protocol |
Previous Message | Joshua Tolley | 2008-12-23 18:28:19 | Re: Proposed Patch to Improve Performance of Multi-Batch Hash Join for Skewed Data Sets |