The following bug has been logged online: Bug reference: 5036 Logged by: Dennis Seran Email address: dse...@novonics.com PostgreSQL version: 8.4 Operating system: Windows XP and RHEL Description: Advisory locks have unexpected behavior Details:
Here is the scenario that was played out step by step: - Everything is running locally on an XP machine. - I have 3 client sessions open on the same machine and logged in the same dB and at this point no exclusive or shared locks are owned. - Client A prompts the command pg_try_advisory_lock_shared(12345) and returns true and obtains shared lock(12345) - Client B prompts the command pg_try_advisory_lock_shared(12345) and returns true and obtains shared lock(12345) - Client B prompts the command pg_advisory_unlock_shared(12345) and returns true thus releasing shared lock(12345) - Client B prompts the command pg_try_advisory_lock_shared(12345) and returns true thus REOBTAINING shared lock(12345) - Client B prompts the command pg_advisory_unlock_shared(12345) and returns true thus RERELEASING shared lock(12345) - Client C prompts the command pg_advisory_lock(12345) and enters the queue to wait since Client A still holds the shared lock(12345) - 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?) - 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?) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
