Re: Standby corruption after master is restarted

2018-04-26 Thread Michael Paquier
On Fri, Apr 27, 2018 at 09:49:08AM +0900, Kyotaro HORIGUCHI wrote: > Thank you for noticing me of that. Is there any way to know how a > bug report has been concluded? Or should I search -hackers for > a corresponding thread? Keeping a look at the list of patches for bugs in the CF app, and lookin

Re: Standby corruption after master is restarted

2018-04-26 Thread Kyotaro HORIGUCHI
Thank you for noticing me of that. Is there any way to know how a bug report has been concluded? Or should I search -hackers for a corresponding thread? At Thu, 26 Apr 2018 21:13:48 +0900, Michael Paquier wrote in <20180426121348.ga2...@paquier.xyz> > On Thu, Apr 26, 2018 at 07:53:04PM +0900, Ky

Re: Standby corruption after master is restarted

2018-04-26 Thread Michael Paquier
On Thu, Apr 26, 2018 at 07:53:04PM +0900, Kyotaro HORIGUCHI wrote: > I think this behavior is a bug. XLogReadRecord is considering the > case but palloc_extended() breaks it. So in the attached, add a > new flag MCXT_ALLOC_NO_PARAMERR to palloc_extended() and > allocate_recordbuf calls it with the

Re: Standby corruption after master is restarted

2018-04-26 Thread Kyotaro HORIGUCHI
Hello. I found how this occurs. # added -hackers I've seen similar case with inadequite operation but this time I found that it can happen under normal operation. At Tue, 17 Apr 2018 17:14:05 +0200, Emre Hasegeli wrote in > > OK, this seems to confirm the theory that there's a race condition