Re: BUG #14180: Segmentation fault on replication slave

From: Bo Ørsted Andresen <boa(at)neogrid(dot)dk>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #14180: Segmentation fault on replication slave
Date: 2016-06-07 18:15:14
Message-ID: VI1PR04MB14881954DB8D5E42483CAED4CB5D0@VI1PR04MB1488.eurprd04.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> On 2016-06-07 20:07, Andres Freund wrote:
> > > > > > Not sure what else I can do short of recompiling postgresql mysql.
> > > > >
> > > > > Any chance the running version of postgres is out of date with
> > > > > the installed binaries / debug symbols?
> > > >
> > > > You mean that I upgraded without restarting postgres before the
> segfault?
> > >
> > > Yes, that's what I was wondering. But alas, that's aparently not the
> reason.
> > >
> > > This is going to be a bit more complicated, sorry :(
> > >
> > > Could you try to reproduce the problem, and do 'p/x ReadRecPtr'?
> > > That should give you something like 0x5434343496. If you rewrite
> > > this as first-four- bytes/last-four-bytes e.g. 54/34343496 you get
> > > the LSN. With that, could you try pg_xlogdump -p
> > > /path/to/data/directory -s 54/34343496 -n 100 and send the output?
> >
> > Will do. May take a while.
>
> To clarify: After the crash recovery continues successfully? Or do you have to
> scrap te standby?

The crash recovery does not continue successfully. I don't know of a way to attach in gdb to the process that crashes before it already crashed, which does not involve scrapping the standby.

Regards,
Bo Ørsted Andresen

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andres Freund 2016-06-07 18:16:35 Re: BUG #14180: Segmentation fault on replication slave
Previous Message Tom Lane 2016-06-07 18:07:32 Re: BUG #14180: Segmentation fault on replication slave