BUG #5036: Advisory locks have unexpected behavior

The following bug has been logged online:

Bug reference: 5036
Logged by: Dennis Seran
Email address: dseran(at)novonics(dot)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?)