On Mon, 2019-04-29 at 10:42 +0200, Dmitry Dolgov wrote:
> > On Mon, Apr 29, 2019 at 10:16 AM Jozef Mlich <
> > jozef.mlich@greycortex.com> wrote:
> >
> > I have automatic logging of segfaults in my lab. I have found a few
> > crashes of postgresql. Unfortunatelly, I am not able to dig more
> > logs
> > or run any query on that machine. I believe, it may help find you
> > some
> > issue.
>
> Thanks for reporting!
>
> > [New LWP 31494]
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library "/lib64/libthread_db.so.1".
> > Core was generated by `postgres: startup recovering
> > 0000000100000000000000EC'.
> > Program terminated with signal 6, Aborted.
> > #0 0x00007f8c02a3e207 in raise () from /lib64/libc.so.6
> >
> > Thread 1 (Thread 0x7f8c053908c0 (LWP 31494)):
> > #0 0x00007f8c02a3e207 in raise () from /lib64/libc.so.6
> > No symbol table info available.
> > #1 0x00007f8c02a3f8f8 in abort () from /lib64/libc.so.6
> > No symbol table info available.
> > #2 0x000000000084d2cb in errfinish (dummy=<optimized out>) at
> > elog.c:555
> > edata = 0xd44560 <errordata>
> > elevel = 22
> > oldcontext = 0x2b713a0
> > econtext = 0x0
> > __func__ = "errfinish"
> > #3 0x000000000050580c in StartupXLOG () at xlog.c:6355
>
> Quick look at this version shows that it's
>
> ereport(FATAL, (errmsg("control file contains invalid data")));
>
> So I guess the chances are high, that this stack trace is not an
> immediate
> result of some issue, but just a statement that something wrong
> happened to a
> control file before.
From further discussion we have identified that we stareted
'/usr/pgsql-11/bin/pg_resetwal -x' with incorrect parameter. I am not
sure if it is a bug or intended behaviour.
--
Jozef Mlich <jozef.mlich@greycortex.com>
