Re: Server process crash - Segmentation fault

Поиск
Список
Период
Сортировка
От Adrian Klaver
Тема Re: Server process crash - Segmentation fault
Дата
Msg-id 5368F257.9060205@aklaver.com
обсуждение исходный текст
Ответ на Server process crash - Segmentation fault  (Leif Jensen <leif@crysberg.dk>)
Ответы Re: Server process crash - Segmentation fault
Список pgsql-general
On 05/06/2014 07:08 AM, Leif Jensen wrote:
>     Hello.
>
>     I was running PostgreSQL 9.1.4 when I got a server process crash (Segmentation fault) as the postgres log shown
below.I tried upgrade to newest version 9.3.4, but this gives exactly the same problem. 
>
>     It is an (ecpg based) C-program that does tons of these scroll cursor exercises. Until recently this worked too
butchanges to totally different part of the program made this happen. (I have made way too many changes to this other
partto be able to "roll back" the code :-( ). The system generates data all the time for this lookup, but I can grab
theSQL from the postgres log and run it through psql and get the result I expect, so I don't see how it can be data
related.
>
>     Please help,
>
>   Leif
>
> .
> .
> .
> 22864 2014-05-06 15:37:35.350 CEST LOG:  statement: close execcurs
> 22864 2014-05-06 15:37:35.350 CEST LOG:  statement: deallocate "ApplDBConn_22854_f6adeb70_query"
> 22864 2014-05-06 15:37:35.352 CEST DEBUG:  parse ApplDBConn_22854_f6adeb70_query: SELECT data_type FROM
information_schema.columnsWHERE table_name = 'l2_hb_water_hours_sum' AND column_name = ''; 
> 22864 2014-05-06 15:37:35.353 CEST LOG:  statement: declare execcurs  scroll cursor  for SELECT data_type FROM
information_schema.columnsWHERE table_name = 'l2_hb_water_hours_sum' AND column_name = ' 
> ';
> 22864 2014-05-06 15:37:35.356 CEST LOG:  statement: fetch first in execcurs
> 22864 2014-05-06 15:37:35.358 CEST LOG:  statement: close execcurs
> 22864 2014-05-06 15:37:35.358 CEST LOG:  statement: deallocate "ApplDBConn_22854_f6adeb70_query"
> 22864 2014-05-06 15:37:35.359 CEST LOG:  statement: commit
> 22864 2014-05-06 15:37:35.359 CEST LOG:  statement: start transaction read only
> 22864 2014-05-06 15:37:35.360 CEST DEBUG:  parse ApplDBConn_22854_f6adeb70_query: SELECT montime, year, month, day,
hh,gal_hour, exp_hour, unsched_hour FROM l2_hb_water_hours_sum  WHERE  l2_hb_water_ 
> hours_sum.ctrlid =  86  ORDER BY year,month,day,hh OFFSET (SELECT CASE WHEN count(*) > 2000 THEN count(*) -2000 ELSE
0END FROM l2_hb_water_hours_sum    WHERE  l2_hb_water_hours_sum.ctrlid =  86 ); 
> 22864 2014-05-06 15:37:35.365 CEST LOG:  statement: declare execcurs  scroll cursor  for SELECT montime, year, month,
day,hh, gal_hour, exp_hour, unsched_hour FROM l2_hb_water_hours_sum  WHERE  l2_hb 
> _water_hours_sum.ctrlid =  86  ORDER BY year,month,day,hh OFFSET (SELECT CASE WHEN count(*) > 2000 THEN count(*)
-2000ELSE 0 END FROM l2_hb_water_hours_sum    WHERE  l2_hb_water_hours_sum.ctrlid =  8 
> 6 );

The code that generates the above would be helpful. The thing that
catches my eye is that the first time you use
ApplDBConn_22854_f6adeb70_query the parse and cursor queries are the
same and all is good. The second time they are not and you get a
failure. Without seeing what is going in in your code it is hard to tell
if this significant or not.

> 22864 2014-05-06 15:37:35.432 CEST LOG:  statement: fetch first in execcurs
> 21702 2014-05-06 15:37:35.440 CEST DEBUG:  server process (PID 22864) was terminated by signal 11: Segmentation fault
> 21702 2014-05-06 15:37:35.440 CEST DETAIL:  Failed process was running: fetch first in execcurs
> 21702 2014-05-06 15:37:35.440 CEST LOG:  server process (PID 22864) was terminated by signal 11: Segmentation fault
> 21702 2014-05-06 15:37:35.440 CEST DETAIL:  Failed process was running: fetch first in execcurs
> 21702 2014-05-06 15:37:35.440 CEST LOG:  terminating any other active server processes


--
Adrian Klaver
adrian.klaver@aklaver.com


В списке pgsql-general по дате отправления:

Предыдущее
От: Leif Jensen
Дата:
Сообщение: Server process crash - Segmentation fault
Следующее
От: bricklen
Дата:
Сообщение: Re: copy expensive local view to an RDS instance