Hi Tatsuo,<br>Just an update: based on your comment:<br>> Probably there's something wrong with the extended query protocol (JDBC)<br><br>I have switched the JDBC from v3 to v2 (Passing protocolVersion=2 to it) as this<br>
will effectively disable extended query. Since doing so (It's been ~4 days) pgpool<br>is yet to crash. Good news thus far.<br><br>If (when) a fix for the original issue is found, please do tell.<br><br><br>Thanks and Regards,<br>
James Elsdon<br><br><div class="gmail_quote">On Wed, Dec 21, 2011 at 12:45 PM, Tatsuo Ishii <span dir="ltr"><<a href="mailto:ishii@postgresql.org">ishii@postgresql.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">>> Thanks for the report. It seems parse tree data was overwritten by<br>
>> garbage. Do you have self contained test case?<br>
><br>
> Unfortunately this is not something that I have been able to reproduce<br>
> manually with a<br>
> 100% strike rate. Re-running the same query in a loop will often see a few<br>
> crashes per<br>
> hour but this is as best as I have been able to manage.<br>
><br>
> Please find attached core dumps of the process along with the pgpool<br>
> configuration (Separate email) .<br>
> Passwords and addresses have been removed from the configuration.<br>
><br>
> In our live system, it would appear to occur in the order of once every 5<br>
> minutes. Production<br>
> utilises connection pools.<br>
<br>
</div>You have a segfault every 5 minutes? Too bad. Probably there's<br>
something wrong with the extended query protocol(via JDBC) and<br>
replication mode. Will look into...<br>
<div class="HOEnZb"><div class="h5">--<br>
Tatsuo Ishii<br>
SRA OSS, Inc. Japan<br>
English: <a href="http://www.sraoss.co.jp/index_en.php" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
Japanese: <a href="http://www.sraoss.co.jp" target="_blank">http://www.sraoss.co.jp</a><br>
<br>
> Regards,<br>
> James Elsdon<br>
><br>
><br>
><br>
>> Hello,<br>
>> > Firstly thanks for pgpool.<br>
>><br>
>> You are welcome!<br>
>><br>
>> > PGPool (confirmed in 3.0.3 and 3.0.5, did not use 3.0.4) will produce the<br>
>> > following behaviour<br>
>> ><br>
>> > pgpool[22132] general protection rip:41668d rsp:7fffb04a0d90 error:0<br>
>> ><br>
>> ><br>
>> > Core dump details below:<br>
>> ><br>
>> > #0 0x000000000041668d in is_sequence_query (node=0x5ff438) at<br>
>> > pool_process_query.c:1528<br>
>> > #1 0x00000000004442fe in pool_where_to_send (query_context=0x602a70,<br>
>> > query=0x5fddb8 "SELECT aaaaaaa, pppppppp, cccc, rrrrrrr, aaaaaa,<br>
>> > cccccccc, fffffffff, sssssss, ddd, gggggg, ppppp, mmmmmm FROM<br>
>> aaaaaaa_ccccc<br>
>> > WHERE aaaaaaa=$1", node=0x5ff438) at pool_query_context.c:447<br>
>> > 447 if (is_select_query(node, query) &&<br>
>> > !is_sequence_query(node))<br>
>> > #2 0x0000000000440b15 in Parse (frontend=0x5f3070, backend=0x5f2040,<br>
>> > len=149, contents=0x610210 "") at pool_proto_modules.c:702<br>
>> > 702 pool_where_to_send(query_context,<br>
>> > query_context->original_query,<br>
>> > #3 0x0000000000441d50 in ProcessFrontendResponse (frontend=0x5f3070,<br>
>> > backend=0x5f2040) at pool_proto_modules.c:2007<br>
>> > 2007 status = Parse(frontend, backend, len,<br>
>> > contents);<br>
>> > #4 0x00000000004163eb in pool_process_query (frontend=0x5f3070,<br>
>> > backend=0x5f2040, reset_request=0) at pool_process_query.c:344<br>
>> > 344 status =<br>
>> > ProcessFrontendResponse(frontend, backend);<br>
>> > #5 0x00000000004094c2 in do_child (unix_fd=4, inet_fd=5) at child.c:328<br>
>> > 328 status = pool_process_query(frontend,<br>
>> > backend, 0);<br>
>> > #6 0x0000000000403f75 in fork_a_child (unix_fd=4, inet_fd=5, id=30) at<br>
>> > main.c:1033<br>
>> > 1033 do_child(unix_fd, inet_fd);<br>
>> > #7 0x00000000004068f5 in main (argc=<value optimized out>, argv=<value<br>
>> > optimized out>) at main.c:517<br>
>> > 517 process_info[i].pid = fork_a_child(unix_fd,<br>
>> > inet_fd, i);<br>
>> ><br>
>> > Core was generated by `pgpool: sss sss 10.10.10.11(3766'.<br>
>> > Program terminated with signal 11, Segmentation fault.<br>
>> > #0 0x000000000041668d in is_sequence_query (node=0x5ff438) at<br>
>> > pool_process_query.c:1528<br>
>> > 1528 if (IsA(lfirst(lc), ResTarget))<br>
>> ><br>
>> > (gdb) print lc->data.ptr_value<br>
>> > $5 = (void *) 0x73202c656d616e74<br>
>> > (gdb) print (int)lc->data.ptr_value<br>
>> > $6 = 1835101812<br>
>> > (gdb) print (ResTarget)lc->data.ptr_value<br>
>> > $7 = {type = 1835101812, name = 0x202c656d616e7275 <Address<br>
>> > 0x202c656d616e7275 out of bounds>, indirection = 0x6e6567202c626f64, val<br>
>> =<br>
>> > 0x6f6870202c726564, location = 539780462}<br>
>> ><br>
>> > Host Details:<br>
>> ><br>
>> > Linux PGPOOL01 2.6.16.60-0.21-smp #1 SMP Tue May 6 12:41:02 UTC 2008<br>
>> x86_64<br>
>> > x86_64 x86_64 GNU/Linux<br>
>> ><br>
>> >> gcc -v<br>
>> > Using built-in specs.<br>
>> > Target: x86_64-suse-linux<br>
>> > Configured with: ../configure --enable-threads=posix --prefix=/usr<br>
>> > --with-local-prefix=/usr/local --infodir=/usr/share/info<br>
>> > --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64<br>
>> > --enable-langux<br>
>> > Thread model: posix<br>
>> > gcc version 4.1.2 20070115 (SUSE Linux)<br>
>><br>
>> Thanks for the report. It seems parse tree data was overwritten by<br>
>> garbage. Do you have self contained test case?<br>
>> --<br>
>> Tatsuo Ishii<br>
>> SRA OSS, Inc. Japan<br>
>> English: <a href="http://www.sraoss.co.jp/index_en.php" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
>> Japanese: <a href="http://www.sraoss.co.jp" target="_blank">http://www.sraoss.co.jp</a><br>
>><br>
</div></div></blockquote></div><br>