Re: BUG #14180: Segmentation fault on replication slave
От | Andres Freund |
---|---|
Тема | Re: BUG #14180: Segmentation fault on replication slave |
Дата | |
Msg-id | 20160607180650.mjg6ghpul6inkzeg@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: BUG #14180: Segmentation fault on replication slave (Bo Ørsted Andresen <boa@neogrid.dk>) |
Ответы |
Re: BUG #14180: Segmentation fault on replication slave
|
Список | pgsql-bugs |
On 2016-06-07 18:04:50 +0000, Bo Ørsted Andresen wrote: > > On 2016-06-07 20:00, Andres Freund wrote: > > > > On 2016-06-07 19:41, 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? Regards, Andres
В списке pgsql-bugs по дате отправления: