Re: BUG #16665: Segmentation fault

ne 11. 10. 2020 v 3:13 odesílatel Raphael Megzari <raphael(at)megzari(dot)com>
napsal:

> ok here is the backtrace that I got
>
> Let me know if you need anything else
>

please, can you install debug symbols for Postgres. In this backtrace is
not detail information.

It's strange so Postgres crashes in LWLockAttemptLock

Maybe there is problem in
https://github.com/postgres/postgres/commit/bb16aba50c9492490a0b57e600a932798f45cd4f

Do you use serializable level of transaction isolations?

> #0 0x0000556931d0ba55 in LWLockAttemptLock ()
> #1 0x0000556931d0c537 in LWLockAcquire ()
> #2 0x0000556931cefe83 in ReadBuffer_common ()
> #3 0x0000556931cf0626 in ReadBufferExtended ()
> #4 0x0000556931a8c9b0 in heapgetpage ()
> #5 0x0000556931a8cf09 in heapgettup_pagemode ()
> #6 0x0000556931a8de3e in heap_getnextslot ()
> #7 0x0000556931bf27fe in SeqNext ()
> #8 0x0000556931bd15b7 in ExecScan ()
> #9 0x0000556931bf115f in ExecNestLoop ()
> #10 0x0000556931bf115f in ExecNestLoop ()
> #11 0x0000556931be1147 in ExecGather ()
> #12 0x0000556931bc8a2b in standard_ExecutorRun ()
> #13 0x00007f10dcb8d345 in pgss_ExecutorRun () from
> /usr/local/lib/postgresql/pg_stat_statements.so
> #14 0x0000556931d1e41c in PortalRunSelect ()
> #15 0x0000556931d1f5d6 in PortalRun ()
> #16 0x0000556931d1cb58 in PostgresMain ()
> #17 0x0000556931caa3d7 in ServerLoop ()
> #18 0x0000556931cab333 in PostmasterMain ()
> #19 0x0000556931a4db7c in main ()
>
>
>
>
> On Saturday, Oct 10, 2020 at 11:57 PM, Pavel Stehule <
> pavel(dot)stehule(at)gmail(dot)com> wrote:
>
>
> so 10. 10. 2020 v 16:51 odesílatel Raphael Megzari <raphael(at)megzari(dot)com>
> napsal:
>
>> I'm not really sure how to read that binary file.
>>
>> I have uploaded to an s3 bucket and made it public.
>> Anyone should be able to access that file
>> *https://s3.eu-central-1.wasabisys.com/union-backups/core_dump.gz
>> <https://s3.eu-central-1.wasabisys.com/union-backups/core_dump.gz>*
>>
>
> this is not good idea
>
> see https://stackoverflow.com/questions/5115613/core-dump-file-analysis
>
> Pavel
>
>
>>
>> it's 2GB
>>
>> If you have a link to a documentation of how I can read that file and get
>> the stacktrace, I would be glad to give it a read.
>>
>>
>>
>> On Saturday, Oct 10, 2020 at 8:56 PM, Pavel Stehule <
>> pavel(dot)stehule(at)gmail(dot)com> wrote:
>>
>>
>> so 10. 10. 2020 v 13:27 odesílatel Raphael Megzari <raphael(at)megzari(dot)com>
>> napsal:
>>
>>> Awesome, thank you!
>>> It's the right thing.
>>>
>>> How do I share it?
>>>
>>
>> important is the backtrace
>>
>> paste it to mail
>>
>>
>>
>>>
>>>
>>> On Saturday, Oct 10, 2020 at 8:24 PM, Pavel Stehule <
>>> pavel(dot)stehule(at)gmail(dot)com> wrote:
>>>
>>>
>>> so 10. 10. 2020 v 13:19 odesílatel Raphael Megzari <raphael(at)megzari(dot)com>
>>> napsal:
>>>
>>>> Thank you for taking the time to have a look.
>>>>
>>>> I'm not sure how to enable core dump with the docker image.
>>>>
>>>> I've seen some documentation where the db is started with pg_ctl anc a
>>>> "c" flag. I couldn't find anything on enabling it on the docker image.
>>>>
>>>> in my data folder, I have a huge core file (8 GB). Would it be possible
>>>> that it is the core dump file generated after the segfault?
>>>>
>>>
>>> you can check a create time
>>>
>>> Pavel
>>>
>>>
>>>> Raphael
>>>>
>>>>
>>>>
>>>>
>>>> On Saturday, Oct 10, 2020 at 6:04 PM, Pavel Stehule <
>>>> pavel(dot)stehule(at)gmail(dot)com> wrote:
>>>> Hi
>>>>
>>>>
>>>>> If I can help in any ways, please let me know.
>>>>> I don't mind trying things, like I said, the bug happens about every 2
>>>>> days.
>>>>>
>>>>
>>>> This is a bug, but from your bug report isn't possible to detect any
>>>> information.
>>>>
>>>> Can you enable core dump generating, and can you send a core dump?
>>>>
>>>> Regards
>>>>
>>>> Pavel
>>>>
>>>>>
>>>>> Cheers!
>>>>>
>>>>>