Re: BUG #16665: Segmentation fault
От | Thomas Munro |
---|---|
Тема | Re: BUG #16665: Segmentation fault |
Дата | |
Msg-id | CA+hUKGJaoOt+4kwUVq5dP97jV0mQjrbfuPfxhvWoASr=7wecFA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #16665: Segmentation fault (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: BUG #16665: Segmentation fault
|
Список | pgsql-bugs |
On Sun, Oct 11, 2020 at 6:37 PM Pavel Stehule <pavel.stehule@gmail.com> wrote: > ne 11. 10. 2020 v 3:13 odesílatel Raphael Megzari <raphael@megzari.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 Yeah that's pretty weird. It's as if it has a bad address for the lock (core data structures corrupted, somehow we got a crazy buffer number from a corrupted buffer mapping table?), or the mapping just went away (systemd removed it? docker/lxc/whatever removed it?), but then I suppose there'd be lots of different failure modes, so it's probably not that. Hmm. In the case we see, it's a parallel query, crashing in the leader process under ExecGather(). Is it always like that? Is it possible to see any variables in the core file? For example, looking in the frame for ReadBuffer_common: frame 2 print (unsigned int) blockNum print &BufferDescriptors print bufHdr print (int) NBuffers > Maybe there is problem in https://github.com/postgres/postgres/commit/bb16aba50c9492490a0b57e600a932798f45cd4f > > Do you use serializable level of transaction isolations? Hmm, I don't see anything in the stack trace or config file that implies that. It was released in 12.
В списке pgsql-bugs по дате отправления: