Re: PG connections going to 'waiting'

From: Joshua Tolley <eggyknap(at)gmail(dot)com>
To: Alan McKay <alan(dot)mckay(at)gmail(dot)com>
Cc: Postgres General Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: PG connections going to 'waiting'
Date: 2009-09-05 19:28:12
Message-ID: 20090905192812.GN416@eddie
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sat, Sep 05, 2009 at 01:08:30PM -0400, Alan McKay wrote:
> > pg_locks?  Somebody taking exclusive lock on a widely-used table might
> > explain that.
>
> OK, in theory we could do the following, no?
>
> Use our PITR logs to restore a tertiary system to the point when we
> were having the problem (we have a pretty wide 2 or 3 hour window to
> hit), then query the pg_locks table on that system?

I'm guessing this wouldn't work. pg_locks isn't a table, it's a view, based on
the pg_lock_status function. I don't know how that function works, but I'm
guessing it gathers lock data from shared memory or some such, and would only
contain the same values it did at the time of the crash if you had the same
queries and autovacuum processes currently in flight. Autovacuum presumably
didn't contribute to the locking in meaningful ways, so if you have logs of
the queries you were running at the time, you might be able to get the same or
a similar condition by executing those queries against the restored system.

--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Andy Colson 2009-09-05 20:14:12 Re: easy task: concurrent select-updates
Previous Message Tom Lane 2009-09-05 19:24:55 Re: PG connections going to 'waiting'