From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | log_lock_waits to identify transaction's relation |
Date: | 2013-01-16 02:42:58 |
Message-ID: | CA+U5nMKOLkzz9AFgT-_Us5w3_C+VxZ8jWUL0AtgW7Ss7Wezfrg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
identify_xact_waits.v1.patch | application/octet-stream | 12.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Claudio Freire | 2013-01-16 02:44:45 | Re: [PATCH] COPY .. COMPRESSED |
Previous Message | Simon Riggs | 2013-01-16 02:40:32 | Sequence Access Method WIP |