Re: postgresql9.1.6 core dump

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

In response to

Browse pgsql-general by date

  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