Jeremy Finzel <finzelj@gmail.com> writes: > On Thu, Feb 14, 2019 at 4:26 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> So my bet is that your problem was fixed by some other commit between >> 10.3 and 10.6. Maybe the predecessor one, b767b3f2e; but hard to say >> without more investigation than seems warranted, if the bug's gone.
> I am willing to put in more time debugging this because we want to know > which clusters are actually susceptible to the bug. Any suggestions to > proceed are welcome.
Well, as Peter said, "git bisect" and trying to reproduce the problem at each step would be the way to prove it definitively. Seems mighty tedious though. Possibly you could shave some time off the process by assuming it must have been one of the commits that touched reorderbuffer.c ... a quick check says there have been ten of those in the v10 branch since 10.3.
regards, tom lane
I am slowly continuing to pursue this, and I hit a slightly different actual segfault on commit 4346794, still on reorderbuffer.c, this time just 2 lines below the original.
I only have 3 more steps to test and I should know exactly what commit fixed the segfault possibility. I still don't know precisely what can reproduce the crash.
