Re: Fix misuse use of window_gettupleslot function (src/backend/executor/nodeWindowAgg.c)

From: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fix misuse use of window_gettupleslot function (src/backend/executor/nodeWindowAgg.c)
Date: 2025-10-06 12:06:08
Message-ID: CAEudQAr4b85RXg8df9AxU+1rrgzSsLb+GXXTRLvb04UW_R=A6Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em seg., 6 de out. de 2025 às 08:33, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
escreveu:

>
> Em dom., 5 de out. de 2025 às 13:05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> escreveu:
>
>> Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> writes:
>> > Per Coverity.
>> > CID 1635309: (#1 of 1): Unchecked return value (CHECKED_RETURN)
>> > 7. check_return: Calling window_gettupleslot without checking return
>> value
>> > (as is done elsewhere 8 out of 9 times).
>>
>> Yeah, the security team's Coverity instance just whined about that
>> too. But isn't the correct behavior simply "return -1"?
>
> It seems to me a better option.
>
>
>> It looks
>> to me like a failure should be interpreted as "row doesn't exist,
>> therefore it's not in frame".
>>
> I also believe that the original author did not expect a failure here.
>
>
>> What would be really useful is a test case that reaches this
>> condition. That would make it plain what to do.
>>
> There is a comment above that indicates that possibly a failure could also
> be the end of the partition.
>
> v1 patch attached.
>
It seems to me that this issue is being addressed in another thread. [1]
I'll withdraw these patch.

best regards,
Ranier Vilela

[1]
https://www.postgresql.org/message-id/20251002.211550.1475922457918078317.ishii%40postgresql.org

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Laurenz Albe 2025-10-06 12:07:47 Re: The ability of postgres to determine loss of files of the main fork
Previous Message Andrew Dunstan 2025-10-06 11:55:47 Re: split func.sgml to separated individual sgml files