From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, xinwen(at)stu(dot)scu(dot)edu(dot)cn, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17777: An assert failed in nodeWindowAgg.c |
Date: | 2023-02-12 10:30:25 |
Message-ID: | CAApHDvpeXSU4A=mzX=96Rdn6u4gjVLHy8SMaVm_g01S8yhfAoQ@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Sat, 11 Feb 2023 at 13:49, Andres Freund <andres(at)anarazel(dot)de> wrote:
> I think we could just add a !contain_subplans() to the code deciding whether
> it's safe to use the movable window optimization?
I think this is a fair way to fix the bug. I think we're pretty
unlikely to disappoint too many people by just disabling the inverse
transitions when the filter has a subplan. I think it'll be rare that
a WindowFunc would even have a filter, let alone one with a subplan.
I think there are other reasons that a subplan might not return the
same thing when it's executed again. Maybe a synchronous seq scan
looking for some tuple with a subquery containing a LIMIT 1. If the
sync scan started in a different place each time then some other tuple
could be returned. So I think checking if the filter contains
subplans is a good fix.
Here's a patch for that.
David
Attachment | Content-Type | Size |
---|---|---|
disable_inverse_transitions_when_filter_has_subplan.patch | text/plain | 1.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-02-12 16:19:41 | Re: BUG #17777: An assert failed in nodeWindowAgg.c |
Previous Message | PG Bug reporting form | 2023-02-12 10:00:01 | BUG #17788: Incorrect memory access when parsing empty string as sql_standard interval |