From: | Tony Day <tonyd(at)panztel(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-novice <pgsql-novice(at)postgresql(dot)org> |
Subject: | Re: What is locktype=transactionid ? |
Date: | 2010-05-18 05:17:58 |
Message-ID: | AANLkTimupf0I-RHZ5H3rsxmMPhTk7G-3CIfNWgzNLlB5@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
Hi Tom
Thanks for the response.
Currently, the only case where anything will try to take a sharelock on
> transaction id is when it is blocking on a row-level lock as a result of
> trying to modify or delete or SELECT FOR UPDATE/FOR SHARE a row that the
> other transaction already modified or deleted or selected FOR
> UPDATE/SHARE.
This helps a lot.
I suspected as much but the locktype of transactionid threw me a bit.
I was expecting a "table" level lock of some sort.
> Given what you're showing in pg_stat_activity, the most likely bet is
> that the "idle in transaction" client is sitting on an uncommitted row
> modification. You need to whack it upside the head and convince it to
> commit or abort its modifications a bit more promptly.
Locating the offending thread (in my multi-threaded process) might be tricky
but once I find it I am now prepared to bludgeon it into submission :-)
Regards, Tony
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Entin | 2010-05-18 10:33:02 | Copy function - how to move text types across |
Previous Message | Tom Lane | 2010-05-18 04:30:39 | Re: What is locktype=transactionid ? |