Re: BUG #14180: Segmentation fault on replication slave

Поиск
Список
Период
Сортировка
От Bo Ørsted Andresen
Тема Re: BUG #14180: Segmentation fault on replication slave
Дата
Msg-id VI1PR04MB14881954DB8D5E42483CAED4CB5D0@VI1PR04MB1488.eurprd04.prod.outlook.com
обсуждение исходный текст
Ответ на Re: BUG #14180: Segmentation fault on replication slave  (Andres Freund <andres@anarazel.de>)
Ответы Re: BUG #14180: Segmentation fault on replication slave  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #14180: Segmentation fault on replication slave
Следующее
От: Andres Freund
Дата:
Сообщение: Re: BUG #14180: Segmentation fault on replication slave