From: | Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | h-shiga(at)big(dot)or(dot)jp, hiroyuki shiga <hshiga(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: postgresql9.1.6 core dump |
Date: | 2013-10-11 19:50:10 |
Message-ID: | 52585672.6010109@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 10/11/2013 08:36 AM, Alvaro Herrera wrote:
> Adrian Klaver escribió:
>> On 10/11/2013 03:51 AM, hiroyuki shiga wrote:
>>> Thank you for reply.
>>>
>>> but .... I can't provide a self-contained test case.
>>>
>>
>> So what are you doing when you get the core dump?
>
> The query is in the backtrace:
>
> SELECT PATH, COUNT(SITE_ID)
> FROM ACCESS_LOG_05
> WHERE SITE_ID = $1
> GROUP BY PATH
> ORDER BY PATH
>
> And it also suggests that the crash is happening during cache lookup of
> the "count" function.
> Since this seems to work for pretty much everybody, I would wonder about
> corrupt catalogs and/or corrupt cache; if neither, perhaps some race
> condition on cache invalidation/reload. Speculating much without any
> further evidence or test case appears pointless.
Which is where I was going with my question. The query would seem to be
the trigger for the core dump, but it does not enlighten as to the lead
up conditions. Basically with out more context answering the question
would involve a lucky guess.
>
--
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Crawford | 2013-10-11 21:30:39 | Re: Need some help on Performance 9.0.4 |
Previous Message | David Johnston | 2013-10-11 19:22:50 | Re: Forms for entering data into postgresql |