Re: BUG #16665: Segmentation fault

út 13. 10. 2020 v 6:38 odesílatel Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
napsal:

> On Sun, Oct 11, 2020 at 6:37 PM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> > 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
>
> 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.
>

true

Pavel