neeraj.punm...@securetogether.com writes: > First database session: > --------------------------- > Lock table Test;
> Second database session > ----------------------- > Select y from Test where x=1 for update nowait; > select query waits until first session releases table lock. This isn't a bug. FOR UPDATE NOWAIT is only meant to specify not waiting for row-level locks on the rows you're trying to lock for update, as per the explanation in the SELECT reference page: To prevent the operation from waiting for other transactions to commit, use the NOWAIT option. With NOWAIT, the statement reports an error, rather than waiting, if a selected row cannot be locked immediately. Note that NOWAIT applies only to the row-level lock(s) - the required ROW SHARE table-level lock is still taken in the ordinary way If it meant "fail on any lock anywhere" the behavior would be too unpredictable. You might consider doing "lock table Test in row share mode nowait" in the second transaction, if you want it to fail on table-level locks too. Another solution is to just use a short statement_timeout rather than NOWAIT clauses. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs