Re: Superuser lost access to particular database - Mailing list pgsql-general

From Francisco Reyes
Subject Re: Superuser lost access to particular database
Date
Msg-id cone.1158386614.231803.47548.1000@zoraida.natserv.net
Whole thread Raw
In response to Superuser lost access to particular database  (Francisco Reyes <lists@stringsutils.com>)
Responses Re: Superuser lost access to particular database
List 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?

pgsql-general by date:

Previous
From: Robert Treat
Date:
Subject: Re: PostgreSQL slammed by PHP creator
Next
From: Martijn van Oosterhout
Date:
Subject: Re: ECPG: non-integer constant in group by