[pgpool-general: 9159] Re: Another segmentation fault

[Tatsuo Ishii]

Hi Emond,

Thanks for the feedback. I am glad to hear that!

Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp

> 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
>>