Re: Superuser lost access to particular database

From: Francisco Reyes <lists(at)stringsutils(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Superuser lost access to particular database
Date: 2006-09-16 06:03:34
Message-ID: cone.1158386614.231803.47548.1000@zoraida.natserv.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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?

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Martijn van Oosterhout 2006-09-16 09:24:55 Re: ECPG: non-integer constant in group by
Previous Message Robert Treat 2006-09-16 00:28:59 Re: PostgreSQL slammed by PHP creator