Re: Lock conflict behavior?

Tatsuo Ishii <ishii(at)postgresql(dot)org> writes:
>> LOCK TABLE checks the permissions before attempting to acquire the lock,
>> is there a reason that ALTER TABLE doesn't?

> Right. I think we should check the permissions first too.

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.

The present coding of LOCK dates from before we had fixed things to
guarantee that relation_open() acquires table lock before attempting to
load the relcache entry. Back then, there were enough race conditions
involved in first access to a relation that one more didn't seem to
matter. But now, I'd sure insist on someone finding a more bulletproof
answer before I'd hold still for extending that bogus coding pattern
all over the system.

regards, tom lane