Updates, ShareLocks, RowExclusiveLocks, and deadlocks - Mailing list pgsql-general

From Ben Chobot
Subject Updates, ShareLocks, RowExclusiveLocks, and deadlocks
Date
Msg-id 2B4CB0E8-7281-43E7-93F9-5BCD3B0FAC10@silentmedia.com
Whole thread Raw
Responses Re: Updates, ShareLocks, RowExclusiveLocks, and deadlocks  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
We have a few daemon process that constantly pull batches of logs from a work queue and then insert into or update a
singletable in a single transaction, ~1k rows at a time. I've been told the transaction does nothing other than insert
andupdate on that table, and I can verify the table in question has no triggers. This is 9.1.3. 

What we've noticed is that most updates come with a RowExclusiveLock, according to pg_locks, which is what you'd expect
fromthe manual. Unfortunately, sometimes, some of those update transactions have ShareLocks, which doesn't make any
senseto us, because we're not taking explicit locks and the manual claims ShareLocks only automatically come from index
creation,which we're also not doing explicitly. This is a problem because it's showing up as deadlocks, every few
minutes.

I've enabled logging all queries and can verify there are no explicit locks an ORM might be doing under our noses. So
atthis point, I'm confused. If we're not explicitly locking, running triggers that might be locking, or creating
indices,where are these ShareLocks coming from? Any suggestions on how to track it down? 

pgsql-general by date:

Previous
From: Steve Crawford
Date:
Subject: Re: postgresql log parsing to report on user/db access
Next
From: Tom Lane
Date:
Subject: Re: Updates, ShareLocks, RowExclusiveLocks, and deadlocks