Alex Hunsaker <badalex@gmail.com> writes:
> FWIW i just tested this with ~100 clients doing begin; ALTER TABLE
> test_lock ADD COLUMN commit; here is the timing. Is there some other
> concern that im not seeing?
The situation where someone quickly acquires the lock isn't much of an
issue, because they'll drop it almost immediately after the permissions
check fails. However consider a scenario like this:
1. Legitimate user U1 does a SELECT on table T and then goes to sleep
with open transaction.
2. Nefarious user U2 does LOCK TABLE T (exclusively). He blocks behind
U1's transaction, since the permissions check won't happen till he gets
the lock.
3. Now, everybody else trying to use table T will queue up behind U2's
request. Their operations might have been perfectly able to run in
parallel with U1's AccessShareLock, but they'll wait behind an
ungranted AccessExclusiveLock.
So it's definitely not a purely academic concern. However, there isn't
any part of this behavior that we can change without breaking other
stuff :-(
regards, tom lane
