Thread: postgres 7.0.3 core dumps
Postgres has core dumped on me a few in the last few weeks. For complete details of the problem: http://www.selectacast.net/~jks/postgres/ I think it is a problem with select from cursor, but I don't really know. -- Joseph Shraibman jks@selectacast.net Increase signal to noise ratio. http://www.targabot.com
Joseph Shraibman <jks@selectacast.net> writes: > Postgres has core dumped on me a few in the last few weeks. For complete > details of the problem: > http://www.selectacast.net/~jks/postgres/ Unfortunately, those core dump files are of no value anywhere except on your machine, since they are (a) platform dependent, and (b) dependent on your executable, which you said was custom-built. Could you go into them with gdb and provide stack backtraces? regards, tom lane
Look at http://www.selectacast.net/~jks/postgres/gdb2.txt and gdb3.txt It looks like script put some garbage in the file where I used file completion in the shell, so just ignore that. Tom Lane wrote: > > Joseph Shraibman <jks@selectacast.net> writes: > > Postgres has core dumped on me a few in the last few weeks. For complete > > details of the problem: > > http://www.selectacast.net/~jks/postgres/ > > Unfortunately, those core dump files are of no value anywhere except > on your machine, since they are (a) platform dependent, and (b) > dependent on your executable, which you said was custom-built. > > Could you go into them with gdb and provide stack backtraces? > > regards, tom lane -- Joseph Shraibman jks@selectacast.net Increase signal to noise ratio. http://www.targabot.com
Oops, I did the trace wrong. <rant> Why can't gdb -c corefile get a symbol table? It prints out what the executable was so it must be able to find it. </rant> Anyway I look at http://www.selectacast.net/~jks/postgres/gdb3.txt The backend was in ExecEvalVar () when it crashed. Tom Lane wrote: > > Joseph Shraibman <jks@selectacast.net> writes: > > Postgres has core dumped on me a few in the last few weeks. For complete > > details of the problem: > > http://www.selectacast.net/~jks/postgres/ > > Unfortunately, those core dump files are of no value anywhere except > on your machine, since they are (a) platform dependent, and (b) > dependent on your executable, which you said was custom-built. > > Could you go into them with gdb and provide stack backtraces? > > regards, tom lane -- Joseph Shraibman jks@selectacast.net Increase signal to noise ratio. http://www.targabot.com
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
Well I finaly got around to trying the to_char function. And I am having difficulty getting it to do what I want elegantly. Here is the situation... I am tracking the time that an event occurs in a column of type time. (seperate column for date). I want to display the time of the event in a fool proof HH:MM (AM | PM) format. As far as I can tell the to_char() function is not overloaded for the time type just timestamp. How do I format a column of type time to HH:MM AM | PM ? I belive the now() function returns a timestamp. but I need a strict time datatype example. Thanks again Jeff Post University of Wisconsin - Milwaukee
Maybe try something like: SELECT to_char(mytable.date + mytable.time, 'HH:MIAM'); That puts your separate date and time fields together into a timestamp, then you can use to_char. If you don't have a mytable.date, I think you could just do: SELECT to_char(CURRENT_DATE + mytable.time, 'HH:MIAM'); In formatting the time part, I don't think it will look at the date part at all. It might not matter what the date actually is in there. On Wednesday 17 January 2001 12:20, Jeffery L Post wrote: > Well I finaly got around to trying the to_char function. And I am having > difficulty getting it to do what I want elegantly. > > Here is the situation... > I am tracking the time that an event occurs in a column of type time. > (seperate column for date). I want to display the time of the event in a > fool proof HH:MM (AM | PM) format. As far as I can tell the to_char() > function is not overloaded for the time type just timestamp. > > How do I format a column of type time to HH:MM AM | PM ? > I belive the now() function returns a timestamp. but I need a strict time > datatype example. > > Thanks again > Jeff Post > University of Wisconsin - Milwaukee -- -------- Robert B. Easter reaster@comptechnews.com --------- -- CompTechNews Message Board http://www.comptechnews.com/ -- -- CompTechServ Tech Services http://www.comptechserv.com/ -- ---------- http://www.comptechnews.com/~reaster/ ------------
Tom Lane wrote: > > 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; > What do I pass into make to do this? > * 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... > From my postgres log (this wasn't from a crash, I'm just showing you what the cursor was like): ProcessUtility: BEGIN; query: DECLARE cname CURSOR FOR SELECT u.userkey, u.profile, u.config, u.rules FROM usertable u, directory d WHERE u.podkey = 2 AND u.status = 2 AND u.subper AND NOT u.banned AND u.userkey = d.userkey AND d.status IN(2, 5); <...> query: FETCH 100 FROM cname; ProcessUtility: FETCH 100 FROM cname; > regards, tom lane -- Joseph Shraibman jks@selectacast.net Increase signal to noise ratio. http://www.targabot.com
Joseph Shraibman <jks@selectacast.net> writes:
>> 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...
>>
> From my postgres log (this wasn't from a crash, I'm just showing you
> what the cursor was like):
> ProcessUtility: BEGIN;
> query: DECLARE cname CURSOR FOR SELECT u.userkey, u.profile, u.config,
> u.rules FROM usertable u, directory d WHERE u.podkey = 2 AND u.status =
> 2 AND u.subper AND NOT u.banned AND u.userkey = d.userkey AND d.status
> IN(2, 5);
> <...>
> query: FETCH 100 FROM cname;
> ProcessUtility: FETCH 100 FROM cname;
Okay. What do you get from EXPLAIN for that SELECT? Actually I'd like
to see EXPLAIN VERBOSE ...
regards, tom lane