Hi, On June 13, 2019 3:38:47 PM PDT, Tom Lane <t...@sss.pgh.pa.us> wrote: >Andres Freund <and...@anarazel.de> writes: >> I am too tired to look further into this. I suspect the only reason >we >> didn't previously run into trouble with the executor stashing >hashkeys >> manually at a different tree level with: >> ((HashState *) innerPlanState(hjstate))->hashkeys >> is that hashkeys itself isn't printed... > >TBH, I think 5f32b29c is just wrong and should be reverted for now. >If there's a need to handle those expressions differently, it will >require some cooperation from the planner not merely a two-line hack >in executor startup. That commit didn't include any test case or >other demonstration that it was solving a live problem, so I think >we can leave it for v13 to address the issue.
I'm pretty sure you'd get an assertion failure if you reverted it (that's why it was added). So it's a bit more complicated than that. Unfortunately I'll not get back to work until Monday, but I'll spend time on this then. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
