Alvaro Herrera <alvhe...@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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
