Subject: Re: Odd blocking (or massively latent) issue - even with
 EXPLAIN
From: Jim Vanns <james.vanns@framestore.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jim Vanns <james.vanns@framestore.com>, pgsql-performance@postgresql.org
In-Reply-To: <29948.1343056156@sss.pgh.pa.us>
References: <1343032905.12579.3.camel@sys367.ldn.framestore.com>
	<29948.1343056156@sss.pgh.pa.us>
Content-Type: text/plain; charset="UTF-8"
Organization: Framestore
Date: Mon, 23 Jul 2012 16:49:25 +0100
Message-ID: <1343058565.12579.126.camel@sys367.ldn.framestore.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Mon, 2012-07-23 at 11:09 -0400, Tom Lane wrote:
> Jim Vanns <james.vanns@framestore.com> writes:
> > We're seeing SELECT statements and even EXPLAIN (no ANAYLZE) 
> > statements hang indefinitely until *something* (we don't know what)
> > releases some kind of resource or no longer becomes a massive bottle
> > neck. These are the symptoms.
> 
> Does anything show up as blocked in the pg_locks view?

Nope.

> Could you attach to the stuck process with gdb and get a stack trace?

Haven't been quite brave enough to do that yet - this is a production
server. I did manage to strace a process though - it (the server side
process of a psql EXPLAIN) appeared to spin on an awful lot of semop()
calls with the occasional read(). Of course, in the context of a shared
memory system such as postgres I'd expect to see quite a lot of semop()
calls but I've no idea how much is normal and how much is excessive.

Jim

> 			regards, tom lane
> 

-- 
Jim Vanns
Systems Programmer
Framestore