Re: Lock conflict behavior?

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

In response to

Responses

Browse pgsql-hackers by date

  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