Yutaka,
On Sun, Sep 16, 2001 at 03:15:02PM +0900, Yutaka tanida wrote:
> On Sat, 15 Sep 2001 10:29:32 -0400
> Jason Tishler <jason@tishler.net> wrote:
>
> > Can you attach to the hung postgres.exe processes and get a backtrace to
> > determine where they are hanging?
>
> Here's log, but it's nothing to use....So,I can't determine what's wrong.
>
> --
> bash-2.05$ gdb -nw
> GNU gdb 5.0 (20010428-1)
> (snip)
> (gdb) attach 776
> Attaching to process 776
> [Switching to thread 776.0x5b0]
> (gdb) backtrace
> #0 0x77fa018d in ?? ()
> #1 0x77e5758a in ?? ()
> --
I believe that you need to start gdb as follows:
$ gdb -nw /usr/bin/postgres.exe
or
$ gdb -nw /usr/local/bin/postgres.exe
as appropriate.
Also, you (usually) need to switch to thread 1 before attempting the
backtrace:
(gdb) thread 1
(gbd) bt
...
And finally, make sure that your postgres.exe is built with debug info
and unstripped.
> There's a backend log when they're hanged.
>
> --
> DEBUG: ProcessUtility: end
> DEBUG: CommitTransactionCommand
> DEBUG: proc_exit(0)
> DEBUG: shmem_exit(0)
> DEBUG: exit(0)
> postmaster: reaping dead processes...
> postmaster: CleanupProc: pid 1480 exited with status 0
> --
>
> I suppose it's a bug of cygwin's signal handling.I'll trying to create
> other testcase.
The above is a good hypothesis. A simple test case will greatly improve
our chances of getting the bug fixed.
BTW, I just tried pgbench last night and was able to get the hang with 12
clients and sometimes 13 worked. Sounds like some kind of race condition.
My postgres.exe is currently stripped -- I will try again tomorrow
(or the next day) with a debuggable executable.
Thanks,
Jason
