[pgpool-general: 1029] Re: Pgpool thread crash, 1 DB backend, replication mode on - Minor
matt.sell at fluke.com
Fri Sep 21 01:05:55 JST 2012
Still fighting GDB, sorry...
In the meantime, here is debug info from syslog from the worker thread that dies:
Sep 20 09:00:16 myCentOSBox pgpool: pgpool-II successfully started. version 3.2.0 (namameboshi)
Sep 20 09:00:37 myCentOSBox pgpool: DB node id: 0 backend pid: 8426 statement: Parse: %=#002
Sep 20 09:00:37 myCentOSBox pgpool: Bind: cannot get parse message ""
Sep 20 09:00:37 myCentOSBox pgpool: do_child: exits with status 1 due to error
Software Engineer III
New Products Introduction Group
> -----Original Message-----
> From: Tatsuo Ishii [mailto:ishii at postgresql.org]
> Sent: Wednesday, September 19, 2012 5:10 PM
> To: Sell, Matt
> Cc: Mills, Curt; pgpool-general at pgpool.net
> Subject: Re: [pgpool-general: 1022] Pgpool thread crash, 1 DB backend,
> replication mode on - Minor
> [Please Cc: to the mailing list to share info. Thanks.]
> > Tatsuo,
> > Could you give an example of the command I should use to generate a
> backtrace that would be helpful in this case?
> > We've tried a number of different ways, but the child process segfault isn't
> being recorded as expected. We're attempting to use "gdb" to execute
> pgpool, but not getting anything meaningful.
> You need to set limit for your pgpool user. i.e.
> $ ulimit coredumpsize unlimited
> If still you don't see core, maybe you need to cd to a directory where the
> user can create a core file. Check permission.
> The other way is, set num_init_children to 1. This way you can identify pid of
> pgpool children. You attach to a process which shows something like this by
> ps command.
> 5054 pts/1 S 0:00 pgpool: wait for connection request
> $ gdb pgpool 5054
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese: http://www.sraoss.co.jp
More information about the pgpool-general