postgres 7.0.3 core dumps

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