From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Christophe Pettus <xof(at)thebuild(dot)com> |
Cc: | PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: "stuck spinlock" |
Date: | 2013-12-13 02:15:29 |
Message-ID: | 22457.1386900929@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Christophe Pettus <xof(at)thebuild(dot)com> writes:
> On Dec 12, 2013, at 5:45 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Presumably, we are seeing the victim rather than the perpetrator of
>> whatever is going wrong.
> This is probing about a bit blindly, but the only thing I can see about this system that is in some way unique (and this is happening on multiple machines, so it's unlikely to be hardware) is that there are a relatively large number of relations (like, 440,000+) distributed over many schemas. Is there anything that pins a buffer that is O(N) to the number of relations?
It's not a buffer *pin* that's at issue, it's a buffer header spinlock.
And there are no loops, of any sort, that are executed while holding
such a spinlock. At least not in the core PG code. Are you possibly
using any nonstandard extensions?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2013-12-13 02:18:03 | Re: SSL: better default ciphersuite |
Previous Message | Christophe Pettus | 2013-12-13 02:12:27 | Re: "stuck spinlock" |