Dennis Seran wrote: > - Client B again prompts the command pg_try_advisory_lock_shared(12345) in > an attempt to reobtain the shared lock(12345) but returns false and fails to > obtain the shared lock (SHOULDN'T THIS CLIENT BE ABLE TO OBTAIN THE SHARED > LOCK?)
No; it gets to sleep until after client C has released the exclusive lock. Otherwise a constant stream of shared lockers would starvate exclusive lockers. > - The above result happens when all 3 clients are on the same machine. If > the same steps were followed, but this time with clients A and B on a RHEL > machine and the client C and the server on an XP machine, the result is a > bit different. The above step results in Client B going into the queue as > well as Client C even though Client A currently holds the shared lock. > (AGAIN, SHOULDN'T THIS CLIENT BE ABLE TO OBTAIN THE SHARED LOCK?) I think this sounds like a bug. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
