> On Thu, Jun 18, 2020 at 06:44:24PM +0200, Dmitry Dolgov wrote:
>
> Yep, I also can reproduce it easily. Can't say I'm familiar with this
> code, but after looking through it a bit it seems something strange is
> going on with a pruning step generated using prefix. Looks like it has
> only expressions for the second attribute of the partition key, but
> tries to compare with the full boundinfo. Without this pruning step the
> query above doesn't crash for me.
After some more investigation it seems that the issue is an empty prefix
in the code mentioned in my previous email. When it's constructed
BTGreaterStrategyNumber is excluded, which makes the logic somehow
dependend on the order or clauses (e.g. the original reported case would
be fine for a table with those two colums in other order), it looks
strange for me. Not sure if the attached fix is correct, but it allows
to avoid empty prefix, avoiding the crash, and passes the tests.