Francisco Reyes <lists@stringsutils.com> writes:
> Going to try the FreeBSD lists to see why and when a process would not
> show up in ktrace. Specially one using 90% cpu.

That's not hard: it's in a loop that doesn't include any kernel calls.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Tom Lane writes:

> So pg_dump seems off the hook. Can you run the query, attach to the
> backend with gdb, and see what it's doing?

As stated on another message tried a ktrace and got nothing.

Trying with gdb.
Is this what you need?
(gdb) bt
#0 0x0811a0a9 in ExecMakeFunctionResult ()
#1 0x0811d0d5 in ExecQual ()
#2 0x0811d573 in ExecScan ()
#3 0x08123b52 in ExecIndexScan ()
#4 0x08118ab1 in ExecProcNode ()
#5 0x081175ac in ExecEndPlan ()
#6 0x08116a98 in ExecutorRun ()
#7 0x0819145d in PortalRun ()
#8 0x0819118c in PortalRun ()
#9 0x0818d729 in pg_plan_queries ()
#10 0x0819025d in PostgresMain ()
#11 0x0816da30 in ClosePostmasterPorts ()
#12 0x0816d24f in ClosePostmasterPorts ()
#13 0x0816b55b in PostmasterMain ()
#14 0x0816aec9 in PostmasterMain ()
#15 0x08133483 in main ()

That was right after entering gdb

Stepping through produced this:
Single stepping until exit from function index_getnext,
which has no line number information.
0x08123aec in ExecReScanHashJoin ()
(gdb) step
Single stepping until exit from function ExecReScanHashJoin,
which has no line number information.
0x0811d545 in ExecScan ()
(gdb) step
Single stepping until exit from function ExecScan,
which has no line number information.
0x081239fc in ExecReScanHashJoin ()
(gdb) step
Single stepping until exit from function ExecReScanHashJoin,
which has no line number information.

At that point it seemed to freeze (gdb) so I did a ktrace on it.

There is a lot of output but some of it is:
47645 gdb RET sigaction 0
47645 gdb CALL wait4(0xffffffff,0xbfbfe538,0,0)
47645 gdb RET wait4 47637/0xba15
47645 gdb CALL sigaction(0x2,0xbfbfe4d0,0xbfbfe4b0)
47645 gdb RET sigaction 0
47645 gdb CALL kill(0xba15,0)
47645 gdb RET kill 0
47645 gdb CALL ptrace(PT_GETREGS,0xba15,0xbfbfe2d0,0)
47645 gdb RET ptrace 0
47645 gdb CALL ptrace(PT_GETDBREGS,0xba15,0xbfbfe440,0)
47645 gdb RET ptrace 0
47645 gdb CALL ptrace(12,0xba15,0xbfbfe280,0)
47645 gdb RET ptrace 0
47645 gdb CALL ptrace(12,0xba15,0xbfbfe280,0)
47645 gdb RET ptrace 0
47645 gdb CALL ptrace(12,0xba15,0xbfbfe280,0)
47645 gdb RET ptrace 0
47645 gdb CALL ptrace(12,0xba15,0xbfbfe280,0)
47645 gdb RET ptrace 0
47645 gdb CALL ptrace(12,0xba15,0xbfbfe280,0)
47645 gdb RET ptrace 0
47645 gdb CALL ptrace(12,0xba15,0xbfbfe280,0)
47645 gdb RET ptrace 0
47645 gdb CALL ptrace(12,0xba15,0xbfbfe280,0)
47645 gdb RET ptrace 0

Is this of any help? Something else I need to try?

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Francisco Reyes <lists@stringsutils.com> writes:
> Trying with gdb.
> Is this what you need?

Unfortunately you're not getting anything very sane, which is a common
result with non-debug-enabled builds. Can you rebuild postgres with
--enable-debug (all other options the same) and try again?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Tom Lane writes:

> Unfortunately you're not getting anything very sane, which is a common
> result with non-debug-enabled builds. Can you rebuild postgres with
> --enable-debug (all other options the same) and try again?

Will do.
Should I go with 8.1.4? Since I have to recompile I could install the
latest. This particular installation has 8.1.3

I figure if I go with 8.1.4 and the issue goes away then at least we know
the problem is solved, however we won't know what it was.

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Francisco Reyes <lists@stringsutils.com> writes:
> Should I go with 8.1.4? Since I have to recompile I could install the
> latest. This particular installation has 8.1.3

Sure, use 8.1.4, just be careful not to change any configure options
from what you had.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly