Skip site navigation (1) Skip section navigation (2)

Re: Apparent deadlock for simultaneous sequential scans

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: bruc(at)acm(dot)org
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Apparent deadlock for simultaneous sequential scans
Date: 2001-06-08 21:51:38
Message-ID: 12114.992037098@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
bruc(at)stone(dot)congenomics(dot)com (Robert E. Bruccoleri) writes:
> With two processors running the same query, it appears to be a
> slowdown.  When I look at the system calls, the backends were
> executing about one read per second. With six processors running the
> same query, it appeared to be a deadlock -- no I/O's were being issued
> over the time that I watched.

It's hard to believe there's an actual deadlock here.  You might be
looking at pathological inefficiency of the spinlock implementation,
but still it seems that someone somewhere must be getting some work
done.  Can you determine which backend actually has the spinlock?
What's it doing?

Given that you mentioned you had a large number of shared buffers,
it might be that a background checkpoint process running BufferSync()
is part of the problem.  It looks like BufferSync acquires the spinlock
separately for each buffer it examines, which would be kinda nasty in
the presence of heavy contention.  OTOH we shouldn't really care if
BufferSync is slow.

			regards, tom lane

In response to

pgsql-bugs by date

Next:From: kyleDate: 2001-06-08 21:54:50
Subject: where clause bug
Previous:From: Tom LaneDate: 2001-06-08 19:29:41
Subject: Re: SELECT on VIEW returns wrong result, Buffer Leak

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group