[pgpool-general: 9158] Re: Another segmentation fault
Emond Papegaaij
emond.papegaaij at gmail.com
Fri Jun 28 15:42:30 JST 2024
Hi,
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:
v1-0001-Fix-segfault-in-a-child-process.patch
fix_main_node_id.patch
fix_segfault2.patch
Best regards,
Emond
Op za 22 jun 2024 om 02:30 schreef Tatsuo Ishii <ishii at sraoss.co.jp>:
> >> What about adding a global variable to pgpool which holds the PID of
> >> the pgpool child process?
> >>
> >
> > That would work, but using the order to match the dumps with the PIDs
> isn't
> > that hard either. Also, the relative ordering of the PIDs is the same for
> > the coredumps and what's reported in the logs. In fact, often (if not
> > always), the offset is the same for all processes. For example, for the
> log
> > from 14136, the PID in the filename is 5117 higher than the PID in the
> log.
> > So the coredump attached to the mail, with PID 5129, was for PID 12. This
> > also matches with the timestamp from the coredump (1718739212000000 =
> > 21:33:32 CEST) and the crash in the log: 2024-06-18 21:33:33: pid 1:
> > WARNING: child process with pid: 12 was terminated by segmentation
> fault.
>
> Ok, I see I can do something like:
>
> test=# SET TIMEZONE TO 'UTC+2';
> SET
> test=# select to_timestamp(1718739212000000/1000000);
> to_timestamp
> ------------------------
> 2024-06-18 17:33:32-02
> (1 row)
>
> or
>
> $ LANG=C TZ='CEST' date --date='@1718739212'
> Tue Jun 18 19:33:32 CEST 2024
>
> Best reagards,
> --
> Tatsuo Ishii
> SRA OSS LLC
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pgpool.net/pipermail/pgpool-general/attachments/20240628/3b2b2f8b/attachment.htm>
More information about the pgpool-general
mailing list