Updates, ShareLocks, RowExclusiveLocks, and deadlocks
От | Ben Chobot |
---|---|
Тема | Updates, ShareLocks, RowExclusiveLocks, and deadlocks |
Дата | |
Msg-id | 2B4CB0E8-7281-43E7-93F9-5BCD3B0FAC10@silentmedia.com обсуждение исходный текст |
Ответы |
Re: Updates, ShareLocks, RowExclusiveLocks, and deadlocks
|
Список | 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 по дате отправления: