Tobias Brox wrote:
I thought so, we have a logging script that logs the content of
the pg_locks table, it didn't log anything interesting but it may be a
problem with the script itself. It does an inner join on
pg_locks.relation = pg_class.oid but when I check now this join seems
to remove most of the rows in the pg_locks table.
Some of the waits you might be running into will be things waiting on
another transaction holding a lock to finish, which are probably wiped
out by this approach. There are some useful examples of lock views on
the wiki:
http://wiki.postgresql.org/wiki/Lock_Monitoring
http://wiki.postgresql.org/wiki/Lock_dependency_information
http://wiki.postgresql.org/wiki/Find_Locks
And the idea you have of coverting the pg_class one to an outer join
will help.
The other thing you should try is toggling on log_lock_waits and
possibly reducing deadlock_timeout. This will put a lot of the
information you're trying to collect right into the logs.
--
Greg Smith, 2ndQuadrant US greg@xxxxxxxxxxxxxxx Baltimore, MD
PostgreSQL Training, Services and Support www.2ndQuadrant.us
Author, "PostgreSQL 9.0 High Performance" Pre-ordering at:
https://www.packtpub.com/postgresql-9-0-high-performance/book
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
