Re: lock contention, need profiling idea

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, AI Rumman <rummandba(at)gmail(dot)com>, pgsql-general General <pgsql-general(at)postgresql(dot)org>
Subject: Re: lock contention, need profiling idea
Date: 2014-07-01 19:32:25
Message-ID: CAHyXU0wFXrxBkAMmv6a3pt1jr7t8Fh5waMSvHor1cZC-xock5w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, Jul 1, 2014 at 2:28 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>> You should have a look at pg_stat_activity, pg_prepared_xacts and pg_locks
>> to get more information about the transactions running and the locks being
>> taken.
>
> In 9.4, the log message will also include info on the blocking
> process, not just the blocked process, for lock waits.
>
> But until then, pg_stat_activity and pg_locks are the best bet.
> Unless you can afford to turn log_statement to 'all' and dig through
> the resulting mess.

log_min_duration_statement might be a middle ground -- set it to 1
second plus. on most applications this should cut out most of the
chaff.

merlin

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Paul Jungwirth 2014-07-01 22:26:54 hstore to json and back again
Previous Message Kynn Jones 2014-07-01 19:30:11 Re: how to create a role with no privileges?