From: | Moshe Jacobson <moshe(at)neadwerx(dot)com> |
---|---|
To: | pgsql-general <pgsql-general(at)postgresql(dot)org>, Chris Autry <chris(at)neadwerx(dot)com> |
Subject: | Strange locking problem |
Date: | 2013-05-21 18:39:57 |
Message-ID: | CAJ4CxLnGpEOd+sNg8TjaLPGxr6dCb-sR2j4MyAB_cBFnavp5Hw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
We have a long-running stored proc that duplicates a particular row in
table called tb_location_map and also duplicates all related rows in
several other tables.
The new records created contain foreign keys to our user data table,
tb_entity. However there is no other reference to tb_entity in the cloning
function <http://pastebin.com/uU0S9x71>.
We are seeing in SOME cases, but not all, that during the execution of this
function, that the corresponding row in tb_entity is locked with a ROW
SHARE lock (according to tb_locks, searching by the user's PID and
tb_entity's relation ID), which is causing updates to the user's data to
block while waiting for the map clone to finish.
What could be causing this ROW SHARE lock to be in place for some cloning
operations and not others? Perhaps there is a way to see which specific
statement is causing the lock to occur, but I'm not sure how to look this
up. Any help would be appreciated.
Thanks!
--
Moshe Jacobson
Nead Werx, Inc. | Manager of Systems Engineering
2323 Cumberland Parkway, Suite 201 | Atlanta, GA 30339
moshe(at)neadwerx(dot)com | www.neadwerx.com
"Quality is not an act, it is a habit." -- Aristotle
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2013-05-21 18:41:11 | Re: pg_upgrade -u |
Previous Message | Richard Onorato | 2013-05-21 18:39:40 | Re: Table Partitioning |