When there is contention between concurrent transactions it shows up as with log_lock_waits as LOG: process %d acquired %s on %s transaction %u after %ld.%03d ms
Which is mostly useless for identifying and eliminating the contention in the application since you can't tell which table is causing problems. This only occurs for lock waits on transactions, not on other lock types, such as tuples which are much more informative, for example LOG: process %d acquired %s on tuple(x,y) of relation %u of database %u after %ld.%03d ms Attached patch passes through further information about the lock wait, so we can display the following message instead LOG: process %d acquired %s on transaction %u on relation %u of database %u after %ld.%03d ms This should help identify benefit/loss from the FKlocks feature, since MultiXactIdWait() shows up in the log as contention of this type. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
identify_xact_waits.v1.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
