On Wed, Jul 1, 2020 at 9:53 PM Dmitry Dolgov <9erthalion6@gmail.com> wrote:
> > 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.
Thanks for the patch, Dmitry! It applies cleanly and make check
passes successfully. I'l look at the patch more closely tomorrow.
Sorry for the late response. I was really busy with other jobs.
Best regards,
Etsuro Fujita
