Обсуждение: Warning: you don't own a lock of type ExclusiveLock
All, I have a recently-migrated Pg cluster running 8.4.7 on Red Hat Enterprise Linux Client release 5.7 (Tikanga) in a VMware VM that is logging the subject warning. The application code is considerably old (deployed back in the 7.4 days, I believe) and the message is preceded by a call to select user_write_unlock(), which is a simple wrapper query that calls pg_advisory_unlock(). What are the causes and possible problems and side-effects of receiving such a log warning? Thank you for any assistance you can provide. -- Gary Chambers
On Sat, Feb 4, 2012 at 8:27 AM, Gary Chambers <gwchamb@gwcmail.com> wrote: > All, > > I have a recently-migrated Pg cluster running 8.4.7 on Red Hat Enterprise > Linux Client release 5.7 (Tikanga) in a VMware VM that is logging the > subject warning. The application code is considerably old (deployed back in > the 7.4 days, I believe) and the message is preceded by a call to select > user_write_unlock(), which is a simple wrapper query that calls > pg_advisory_unlock(). What are the causes and possible problems and > side-effects of receiving such a log warning? Thank you for any assistance > you can provide. That means that you didn't have the lock you were trying to release. Whether that indicates a critical error or not depends on application logic. ChrisA
Chris (et al.), Thanks for the reply. I have not replied sooner because I was hoping to get some more feedback from the list. >> I have a recently-migrated Pg cluster running 8.4.7 on Red Hat Enterprise >> Linux Client release 5.7 (Tikanga) in a VMware VM that is logging the >> subject warning. The application code is considerably old (deployed back >> in the 7.4 days, I believe) and the message is preceded by a call to >> select user_write_unlock(), which is a simple wrapper query that calls >> pg_advisory_unlock(). What are the causes and possible problems and >> side-effects of receiving such a log warning? Thank you for any >> assistance you can provide. Warning: you don't own a lock of type ExclusiveLock > That means that you didn't have the lock you were trying to release. > Whether that indicates a critical error or not depends on application > logic. The application appears to be functioning without issue, but I still have some concerns. One possible cause of the warning I considered was having the VM underlying storage NFS-mounted on a NetApp. Is it possible that Postgres is not receiving a meaningful response with respect to ExclusiveLock locking (i.e. unable to really obtain an ExclusiveLock) due to VM "disk" residing on an NFS mount? -- Gary Chambers
On Fri, Feb 10, 2012 at 2:35 AM, Gary Chambers <gwchamb@gwcmail.com> wrote: > Is it possible that > Postgres is not receiving a meaningful response with respect to > ExclusiveLock locking (i.e. unable to really obtain an ExclusiveLock) due to > VM "disk" residing on an NFS mount? pg_advisory_unlock (along with the other functions in that family) works on a set of mythical objects with no actual meaning beyond what the database administrator chooses to give them. You lock and unlock these ethereal "things", just numbers off a set of tables, with no relationship to NFS mounts, tables, records, or anything else. In (the current iteration of) the priority-queue I wrote for work, each queue-pumping process takes an exclusive lock on a "partition", where a partition is one fraction of the available ID space, using modulo arithmetic. At least, that's what I, the programmer, see; to Postgres, it just takes an exclusive lock on (42,64) or some other pair of numbers. That lock will succeed or fail only on the basis of other advisory lock calls, nothing else can affect it. Chris Angelico
Chris, > pg_advisory_unlock (along with the other functions in that family) works > on a set of mythical objects with no actual meaning beyond what the > database administrator chooses to give them. Thank you for your excellent description. I have never used the advisory lock functionality that Postgres provides, and your reply combined with Merlin's multi-part primer on them, it's easy to see their value, application, and implementation. Finally, with respect to my original request, it's quite conceivable that the application is attempting to free the lock more times than it requested it. Thank you again for your reply! -- Gary Chambers