Tom,
I ran the test scenario again and it appears that you are right. The
first test most likely was executed with the command
"pg_try_advisory_lock(12345)" instead of
"pg_try_advisory_lock_shared(12345)" as you stated. When I ran the
scenario again using "pg_try_advisory_lock_shared(12345)", the result was
the same as when it was run on the same machine, which was a "false"
return.
Thanks for your help and clarifying this for us.
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Saturday, September 05, 2009 6:02 PM
To: Alvaro Herrera
Cc: Dennis Seran; pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #5036: Advisory locks have unexpected behavior
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Dennis Seran wrote:
>> - 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.
It's really, really, really hard to believe that the behavior of
advisory locks would vary depending on where the client is located.
What I think is more likely is that there was some pilot error involved,
such as entering "pg_try_advisory_lock(12345)" instead of
"pg_try_advisory_lock_shared(12345)". Another line of thought is that
the client code being used on the RHEL machine might not be the same as
what is on the XP machine, and is issuing slightly different commands.
regards, tom lane
