Re: Segmentation Fault in logical decoding get/peek API

On Thu, Feb 14, 2019 at 5:05 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Jeremy Finzel <finzelj(at)gmail(dot)com> writes:
> > On Thu, Feb 14, 2019 at 4:26 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

The first segfault I was getting was on:
Assert(specinsert->data.tp.oldtuple == NULL);

Now it's on this:
change->action = REORDER_BUFFER_CHANGE_INSERT

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.

Thanks,
Jeremy