<div dir="ltr">Hi,<div><br></div><div>I just wanted to report that we haven't seen any segmentation fault for the past week now. So it seems the patches really make a difference. These are the patches that we've applied on 4.5.2:</div><div>v1-0001-Fix-segfault-in-a-child-process.patch<br>fix_main_node_id.patch<br>fix_segfault2.patch<br></div><div><br></div><div>Best regards,</div><div>Emond</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Op za 22 jun 2024 om 02:30 schreef Tatsuo Ishii <<a href="mailto:ishii@sraoss.co.jp">ishii@sraoss.co.jp</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>> What about adding a global variable to pgpool which holds the PID of<br>
>> the pgpool child process?<br>
>><br>
> <br>
> That would work, but using the order to match the dumps with the PIDs isn't<br>
> that hard either. Also, the relative ordering of the PIDs is the same for<br>
> the coredumps and what's reported in the logs. In fact, often (if not<br>
> always), the offset is the same for all processes. For example, for the log<br>
> from 14136, the PID in the filename is 5117 higher than the PID in the log.<br>
> So the coredump attached to the mail, with PID 5129, was for PID 12. This<br>
> also matches with the timestamp from the coredump (1718739212000000 =<br>
> 21:33:32 CEST) and the crash in the log: 2024-06-18 21:33:33: pid 1:<br>
> WARNING:  child process with pid: 12 was terminated by segmentation fault.<br>
<br>
Ok, I see I can do something like:<br>
<br>
test=# SET TIMEZONE TO 'UTC+2';<br>
SET<br>
test=# select to_timestamp(1718739212000000/1000000);<br>
      to_timestamp      <br>
------------------------<br>
 2024-06-18 17:33:32-02<br>
(1 row)<br>
<br>
or <br>
<br>
$ LANG=C TZ='CEST' date --date='@1718739212'<br>
Tue Jun 18 19:33:32 CEST 2024<br>
<br>
Best reagards,<br>
--<br>
Tatsuo Ishii<br>
SRA OSS LLC<br>
</blockquote></div>