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 :-)
