On Thu, 7 Nov 2019 at 22:45, Ashutosh Sharma <ashu.coe...@gmail.com> wrote:
> On Thu, Nov 7, 2019 at 7:35 PM Robert Haas <robertmh...@gmail.com> wrote: > > > > On Thu, Nov 7, 2019 at 1:15 AM Ashutosh Sharma <ashu.coe...@gmail.com> > wrote: > > > @Robert, Myself and Prabhat have tried running the test-cases that > > > caused the checkpointer process to crash earlier multiple times but we > > > are not able to reproduce it both with and without the patch. However, > > > from the stack trace shared earlier by Prabhat, it is clear that the > > > checkpointer process panicked due to fsync failure. But, there is no > > > further data to know the exact reason for the fsync failure. From the > > > code of checkpointer process (basically the function to process fsync > > > requests) it is understood that, the checkpointer process can PANIC > > > due to one of the following two reasons. > > > > Oh, I didn't realize this was a panic due to an fsync() failure when I > > looked at the stack trace before. I think it's concerning that > > fsync() failed on Prabhat's machine, and it would be interesting to > > know why that happened, but I don't see how this patch could possibly > > *cause* fsync() to fail, so I think we can say that whatever is > > happening on his machine is unrelated to this patch -- and probably > > also unrelated to PostgreSQL. > > > > That's right and that's exactly what I mentioned in my conclusion too. > > In fact, I suspect this is PostgreSQL successfully protecting itself from an unsafe situation. Does the host have thin-provisioned storage? lvmthin, thin-provisioned SAN, etc? Is the DB on NFS? -- Craig Ringer http://www.2ndQuadrant.com/ 2ndQuadrant - PostgreSQL Solutions for the Enterprise
