yancya@upec.jp writes:
> TRAP: FailedAssertion("!(compareResult < 0)", File: "nodeMergejoin.c", Line:
> 942)
This is not a mergejoin logic bug, because nodeMergejoin.c didn't change
significantly between 9.4 and 9.5. It must be that the input data is not
being delivered in the expected order. I first thought that Peter G's
sorting optimizations must be at fault, but if you run either of the
mergejoin's subplans in isolation, you get correctly sorted data. What
must be happening, then, is that mergejoin's mark/restore operations are
confusing the btree indexscan and causing it to deliver the wrong tuple(s)
after a restore.
Armed with that conclusion about where the bug probably is, I looked
through the git history, and soon found that the crash goes away if
I manually revert commit 2ed5b87f96d473962ec5230fd820abfeaccb2069.
In short: Kevin, you broke mark/restore. Please fix.
regards, tom lane
