Re: Bug in row_number() optimization - Mailing list pgsql-hackers

From David Rowley
Subject Re: Bug in row_number() optimization
Date
Msg-id CAApHDvrpPx3gWQahDSUK_=PBdDgbkqOADe2-1btZDfLfDZ-ACQ@mail.gmail.com
Whole thread Raw
In response to Re: Bug in row_number() optimization  (Sergey Shinderuk <s.shinderuk@postgrespro.ru>)
Responses Re: Bug in row_number() optimization
List pgsql-hackers
On Fri, 25 Nov 2022 at 00:52, Sergey Shinderuk
<s.shinderuk@postgrespro.ru> wrote:
> Shouldn't we handle any pass-by-reference type the same? I suppose, a
> user-defined window function can return some other type, not int8.

Thanks for reporting this and to you and Richard for working on a fix.

I've just looked at it and it seems that valgrind is complaining
because a tuple formed by an upper-level WindowAgg contains a pointer
to free'd memory due to the byref type and eval_windowaggregates() not
having been executed to fill in ecxt_aggvalues and ecxt_aggnulls on
the lower-level WindowAgg.

Since upper-level WindowAggs cannot reference values calculated in
some lower-level WindowAgg, why can't we just NULLify the pointers
instead? See attached.

It is possible to have a monotonic window function that does not
return int8.  Technically something like MAX(text_col) OVER (PARTITION
BY somecol ORDER BY text_col) is monotonically increasing, it's just
that I didn't add a support function to tell the planner about that.
Someone could come along in the future and suggest we do that and show
us some convincing use case.  So whatever the fix, it cannot assume
the window function's return type is int8.

David

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Allow file inclusion in pg_hba and pg_ident files
Next
From: Jose Arthur Benetasso Villanova
Date:
Subject: Re: Amcheck verification of GiST and GIN