|
|
|
|
|
Of course it's not normal. Can you provide stack trace of the segfault process? |
|
|
Added GBD, did you need this? gdb.txt (11,863 bytes) |
|
|
Sorry for delay. gdb.txt looks like a stack trace of Pgpool-II parent process. What I wanted was the stack trace of pgpool child process which segfaults. To get the stack trace, you need to let the pgpool child process produce a core dump file, and take a stack trace from the core file. Can you please do that? |
|
|
In the attachment |
|
|
Thanks. It's pretty strange. Maybe someone broke memory... |
|
|
I have 2 identical virtual servers running multiple instances of pgpool on different ports, could there be a problem because of this? |
|
|
For clarity, added a screen with running pgpool in the attachment Снимок.JPG (176,068 bytes) |
|
|
> I have 2 identical virtual servers running multiple instances of pgpool on different ports, could there be a problem because of this? No I don't think so. Pgpool-II's bult-in regression test regularly runs multiple pgpool instances on a physical/virtual machine without problem. I have asked help from Muhammad Usama who is an authority of PCP subsystem. |
|
|
Is there new information? |
|
|
I have changed the person in charge from me to Usama, who is the authority in this area. |
|
|
Thanks, Xavok for providing the gdb stack trace that really helped to quickly pinpoint the issue. I have pushed the fix to all affected branches. https://git.postgresql.org/gitweb?p=pgpool2.git;a=commitdiff;h=75432c06bda37ff9c15e3e586624e21218a0a40c cheers |
- Anonymous
