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