Re: postgres 7.0.3 core dumps
От | Tom Lane |
---|---|
Тема | Re: postgres 7.0.3 core dumps |
Дата | |
Msg-id | 17054.979746922@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: postgres 7.0.3 core dumps (Joseph Shraibman <jks@selectacast.net>) |
Ответы |
Re: Time Formats
|
Список | pgsql-general |
Joseph Shraibman <jks@selectacast.net> writes: > Anyway I look at http://www.selectacast.net/~jks/postgres/gdb3.txt The > backend was in ExecEvalVar () when it crashed. It sort of looks like the plan generated for a mergejoin must have been bogus, but with only routine names to go on, it's hard to tell more. Ways to get more info: * Recompile backend with -g (--enable-debug), so that next coredump will provide a more informative backtrace; * Run postmaster with -d2 so that queries are logged. You'l need to have compiled with #define ELOG_TIMESTAMPS (uncomment this in src/include/config.h after configuring) so that log entries have PID identifiers, which you'll then be able to correlate to the PID of the crashed backend. This'll tell us just what the failed backend had been doing. If it is a select from cursor that's dying, we'll really need the query log so that we can see what the cursor definition was... regards, tom lane
В списке pgsql-general по дате отправления: