<div dir="ltr"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Do you have an issue with "indexed health checks"? I thought it was<br>
fixed in 3.7.1.<br>
<br></blockquote><div><br></div><div>I was working through debugging my problem, my debug logs were full of health checks reports. I was experimenting with controlling each one individually. I can confidently report that health_check_period and health_check_periodN work quite well. :)<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've also added an extra pre-start step, which removes the<br>
> pgpool_status file.<br>
<br>
That might be a solution but I would like to add a guard to Pgpool-II<br>
against the segfault. The segfault occurs when conditions below are<br>
all met:<br>
<br>
1) fail_over_on_backend_error is off.<br>
2) ALWAYS_MASTER flags is set to the master (writer) node.<br>
<br>
Attached patch implements the guard against the segfault. Developers<br>
will start a discussion regarding the patch in pgpool-hackers.<br></blockquote><div><br></div><div>That sounds like a good idea. You might also consider doing the same for the socket files. <br><br>I ran into issues with lingering sockets. I'm on an ubuntu system, running upstart. At some point, I ran <span style="font-family:monospace">stop pgpool.</span> I tried <span style="font-family:monospace">start pgpool</span> a few minutes later. I found that it could not start, because the socket files had not been removed during shutdown and pgpool would not remove them during startup. My init script removes the socket files from the run directory and the state file from the log directory.<br><br></div><div>I also think it would be great if pgpool exposed the number of zero, non-zero, and exits due to signals the children generated. Parsing the log for that will be a bit cumbersome. <br><br></div><div>Thanks for the great work! :)<br></div></div></div>