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 11:33:10 |
Message-ID: | CAEudQArnsT_VRAGPDDsUV1ObKrczCgJ8XtWCPPW6ikv+VGYsPg@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
best regards,
Ranier Vilela
Attachment | Content-Type | Size |
---|---|---|
v1-fix-api-misuse-function-window_gettupleslot.patch | application/octet-stream | 573 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Jingtang Zhang | 2025-10-06 11:39:18 | Lock tag of relation extend lock |
Previous Message | Aya Iwata (Fujitsu) | 2025-10-06 11:21:02 | RE: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE |