Re: BUG #14180: Segmentation fault on replication slave - Mailing list pgsql-bugs

From Bo Ørsted Andresen
Subject Re: BUG #14180: Segmentation fault on replication slave
Date
Msg-id VI1PR04MB14881954DB8D5E42483CAED4CB5D0@VI1PR04MB1488.eurprd04.prod.outlook.com
Whole thread Raw
In response to Re: BUG #14180: Segmentation fault on replication slave  (Andres Freund <andres@anarazel.de>)
Responses Re: BUG #14180: Segmentation fault on replication slave  (Andres Freund <andres@anarazel.de>)
List 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
beforeit already crashed, which does not involve scrapping the standby. 

Regards,
Bo Ørsted Andresen



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #14180: Segmentation fault on replication slave
Next
From: Andres Freund
Date:
Subject: Re: BUG #14180: Segmentation fault on replication slave