Hello Adrian, Thank you for your answer. I can post part of the code that makes these calls, but I'm not sure how much it would help. It is rather large function that makes these calls, and it is called all over the program. The part of the log posted is only a small excerpt of the use of the ApplDBConn_22854_f6adeb70_query, which has been used many many times before the log shown (167 in all to be exact ;-) ). Leif ----- Original Message ----- > 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 but changes to > > totally different part of the program made this happen. (I have > > made way too many changes to this other part to be able to "roll > > back" the code :-( ). The system generates data all the time for > > this lookup, but I can grab the SQL 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.columns WHERE 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.columns > > WHERE 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 0 END 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(*) -2000 ELSE 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@xxxxxxxxxxx
