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: | Re: Strange locking problem |
Date: | 2013-05-21 19:24:04 |
Message-ID: | CAJ4CxL=RF5FsvSzmx74kPJCd_g-hM95KJvgY6i94yYEWRuPEZg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, May 21, 2013 at 2:39 PM, Moshe Jacobson <moshe(at)neadwerx(dot)com> wrote:
> 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.
>
Update:
Apparently the hanging updates to tb_entity are not only related to
fn_clone_location_map(), because a hung update to tb_entity did not
correspond to a running instance of fn_clone_location_map().
I looked at pg_locks for one hung update to tb_entity, and it said it had
an un-granted lock of type transactionid, for another transaction ID.
I wanted to see what was happening in that transaction ID that might be
causing this lock to be held, but I was unsure how. I know I can look in
pg_locks for the other transaction, but that will not tell me what
statement is executing in that transaction. pg_stat_activity does not have
a transaction ID column.
How can I see what statement is executing in a transaction?
--
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 | Dev Kumkar | 2013-05-21 19:32:18 | Re: [ODBC] ODBC constructs |
Previous Message | John R Pierce | 2013-05-21 19:16:05 | Re: [ODBC] ODBC constructs |