<div dir="ltr"><div dir="ltr">Op wo 3 apr 2024 om 13:36 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">> Is there any way I can help you track down the cause of this issue? In our<br>
> test setup, it is fairly easy to reproduce, so I can add additional logging<br>
> if needed. I'm currently rerunning the tests with the fix for the<br>
> uninitialized value and report back with the results (this does take a<br>
> couple of hours).<br>
<br>
If you could provide a self contained test case, especially using<br>
pgpool_setup or watchdog_setup, it would be very helpful to me.<br></blockquote><div><br></div><div>I was afraid this was going to be your answer :) Unfortunately, I really don't know what sequence of events and actions triggers the error. All I know is that our reboot test triggers it. Also, I don't know how to setup such a test case. The main sequence of events is as follows:</div><div><br></div><div>* Startup the cluster using the following steps<br>  - Start the database on node 1 and make sure it is the primary database</div><div>  - Start pgpool on node 1 and wait a few seconds</div><div>  - Start pgpool on node 2 and 3 and wait a few seconds</div><div>  - Initialize the databases on node 2 and 3, setting them up as standby</div><div>  - The result now is: node 1 is primary db and leader, node 2 and 3 are standby db and standby pgpool watchdog</div><div>* Shtudown and reboot node 2</div><div>* Wait for node 2 to come back up</div><div>* Shutdown and reboot node 3</div><div>* Wait for node 3 to come back up<br></div><div>* Restart pgpool on node 1 to force it to drop its leader status and wait a few seconds</div><div>* Shutdown and detach the database on node 1 to trigger a failover and wait for a new primary to be selected </div><div>* Wait 10 more seconds</div><div>* Rewind the database on node 1 and instruct it to follow the new primary</div><div>* (CRASH ON NODE 2) Wait for the now standby database on node 1 to be fully synchronized with the new primary</div><div>* (CRASH ON NODE 1) Shutdown and reboot node 1</div><div>* Wait for node 1 to come back up</div><div>* Verify the integrity of the cluster (all databases and pgpool instances must be up)</div><div><br></div><div>With Valgrind, I've been able to determine that the SIGSEGV on node 1 has the same backtrace as the SIGSEGV on node 3 (the one in free_persistent_db_connection_memory). I'm not sure about the exact moment for the crash on node 3, as it happens less frequently and I don't have reliable logs of a crash at the moment. The crash on node 2 (get_query_result in pool_worker_child.c) is by far the most frequent, happening about 2 out of 3 times. It seems to happen at the moment when the database on node 1 is started up again, which triggers a failback. When the database on node 1 reports "database system is ready to accept read only connections", only a few ms later, the SIGSEGV happens on node 2.</div><div><br></div><div>I dove into the code, and I think I've found the cause of the error. Just prior to crashing, it reports "find_primary_node: make_persistent_db_connection_noerror failed on node 0". This must come from pgpool_main.c:2782. This means that slots[0] is NULL. Then, at pgpool_main.c:2791 it enters verify_backend_node_status with this slots array. At lines 2569-2579 it loops over these slots, calling get_server_version for every slot, including slots[0], which is NULL. This crashes when get_server_version calls get_query_result, which tries to dereference slots[0]->con. At pgpool_main.c:2456 there is an explicit check for NULL, this is missing in the other for loop, but it is also missing at line 2609.</div><div><br></div><div>I've attached another log from node 2, with the latest patch applied. I still see some uninitialized values. I've enabled origin tracking in valgrind to get detailed information on the origin of the uninitialized values.</div><div><br></div><div>Best regards,</div><div>Emond</div></div></div>