From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: hung backends stuck in spinlock heavy endless loop |
Date: | 2015-01-13 22:40:20 |
Message-ID: | CAHyXU0wJ8miyW2fPh7sNc5Wx1UzUogT_Y8gWvZgMo3BjUyYNjw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jan 13, 2015 at 4:33 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> Hi,
>
> On 2015-01-13 16:29:51 -0600, Merlin Moncure wrote:
>> On my workstation today (running vanilla 9.4.0) I was testing some new
>> code that does aggressive parallel loading to a couple of tables. It
>> ran ok several dozen times and froze up with no external trigger.
>> There were at most 8 active backends that were stuck (the loader is
>> threaded to a cap) -- each query typically resolves in a few seconds
>> but they were hung for 30 minutes+.
>
> Interesting.
>
>> Had to do restart immediate as
>> backends were not responding to cancel...but I snapped a 'perf top'
>> before I did so. The results were interesting so I'm posting them
>> here. So far I have not been able to reproduce...FYI
>
> Can you compile postgres with -fno-omit-frame-pointer? Then, when this
> happens the next time, you can take a perf record -g, which will tell us
> which lock the contention is at.
will do, and I'll loop it for a while and see if I can get it to re-occur.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2015-01-13 23:17:15 | Re: hung backends stuck in spinlock heavy endless loop |
Previous Message | Andres Freund | 2015-01-13 22:33:30 | Re: hung backends stuck in spinlock heavy endless loop |