Postgres ShareRowExclusiveLock lock

I have a loading Postgres server with a large number of update operations. In Postgres.conf I set the deadlock_timeout=8s.

In the log I see the following:

process 3588 acquired ShareRowExclusiveLock on relation 17360 of database 16392 after 
8000.000 ms

This seems really slow. What is your opinion on this? Is there a better value for deadlock_timeout? What other settings can help bring down lock times? And this line from the log says that the transaction was broken and any 开发者_运维知识库data was not updated?

ShareRowExclusiveLocks are acquired when you've explicitly issued a LOCK TABLE statement. The default behavior for LOCK TABLE is to request exclusive access to the table: nobody will be able to read from it until the lock is released.

PostgreSQL uses multi-version concurrency control to handle transactional integrity within the database. Unless you're seeing application problems, I suggest turning off your explicit use of LOCK TABLE or else trying to run your bulk update operation after hours.

I'd also suggest looking into the Explicit Locks documentation if you do need to take explicit locks.

Have you read this?

http://www.postgresql.org/docs/current/static/runtime-config-locks.html

Ideally the setting should exceed your typical transaction time, so as to improve the odds that a lock will be released before the waiter decides to check for deadlock.