<div dir="ltr"><div dir="ltr">Op do 4 apr 2024 om 10:03 schreef Tatsuo Ishii <<a href="mailto:ishii@sraoss.co.jp">ishii@sraoss.co.jp</a>>:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>> But there's a check at line 2604 of pgpool_main.c:<br>
>><br>
>> if (pool_node_status[j] == POOL_NODE_STATUS_STANDBY)<br>
>><br>
>> If pool_node_status[j] is POOL_NODE_STATUS_STANDBY, the target node<br>
>> (0) must be alive in the past. I suspect node 0 goes down after the<br>
>> pool_node_status[j] was updated. I should have checked slots<br>
>> availability before calling get_query_result at 2609.<br>
>><br>
> <br>
> I wasn't sure about line 2609, but adding a check does make sense. The loop<br>
> at lines 2569-2579 definitely is broken. This also is where the segfault<br>
> happens at this moment. I've attached a patch (against 4.5.1) that should<br>
> address this issue.<br>
<br>
Thanks. You are right. I will push your change.<br>
<br>
> Great. I've added the patch to our build, including the attached patch and<br>
> I'm rerunning the tests. I did have to alter the patch for<br>
> pool_worker_child.c a bit to make it apply on 4.5.1.<br>
<br>
Thank you!<br></blockquote><div><br></div><div>I can confirm that with all patches applied, I no longer see any segmentation faults in our tests. I will add explicit checks for coredumps and segfaults in our testsuite, so we can keep monitoring this. It seems we've got them all fixed now. Thanks for the great support!</div><div><br></div><div>Best regards,</div><div>Emond </div></div></div>