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
|
Список | 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 по дате отправления: