Oh, I have little doubt there's a better way to solve the actual problem--this actually resulted from some buggy code that passed a bunch of unexpected arguments to a query generating function. I would note that this did reproduce for me on a different system with some different specs.
I will follow-up with a stack trace. In the meantime, a more accessible version of the reproduction script has been placed at the following address:
PG Bug reporting form <noreply@postgresql.org> writes: > I have encountered a segmentation fault running a particular query.
Given the shape of the query and the fact that it's calling a recursive function, I'm suspicious that this is caused by a stack overrun that we've missed checking for. If so, it might not reproduce for someone else, unless they were running with the exact same physical stack limit (not max_stack_depth, but the kernel limit) as you are, and a similar compiler.
If my idea is right, the whole trace would be very long (probably thousands of stack frames) but the first hundred or so ought to be enough to diagnose.
BTW, seems like there's gotta be a more efficient way to solve your problem than a 14000-way INTERSECT.