From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | xinwen(at)stu(dot)scu(dot)edu(dot)cn, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17826: An assert failed in /src/backend/optimizer/util/var.c |
Date: | 2023-03-11 17:23:56 |
Message-ID: | 1229467.1678555436@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Fri, 10 Mar 2023 at 05:09, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2023-03-11 18:05:20 | BUG #17832: ERROR: failed to apply nullingrels to a non-Var in HEAD |
Previous Message | Tom Lane | 2023-03-11 16:39:30 | Re: BUG #17830: Incorrect memory access in trgm_regexp |