Re: BUG #17826: An assert failed in /src/backend/optimizer/util/var.c

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
Cc: xinwen@stu.scu.edu.cn, pgsql-bugs@lists.postgresql.org
Date: 2023-03-11T17:23:56Z
Lists: pgsql-bugs
David Rowley <dgrowleyml@gmail.com> writes:
> On Fri, 10 Mar 2023 at 05:09, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> How is this even a little bit sane?

> I don't think it is.  I've not looked in detail yet, but I think we
> might be able to do something in check_output_expressions() so that we
> track the targetIsInAllPartitionLists() separately.  Maybe
> unsafeColumns[] needs to become an enum type that has UNSAFE, SAFE,
> WINDOW_RUNCONDITION_ONLY and then change things so we never make a
> runCondition when the qual is UNSAFE.

> Anyway, I'll give it more thought and aim to come up with a patch
> early next week.

Why can't we simply *remove* all this logic from subquery pushdown?

I would expect that what happens in useful cases is that we push down
the (safe) qual and then during planning of the subquery we see a WHERE
clause matching the window run condition and work with that.  So this
all seems redundant, quite aside from being faulty.

			regards, tom lane



Commits

  1. Fix incorrect logic for determining safe WindowAgg run conditions

  2. Teach planner and executor about monotonic window funcs