Fix misuse use of window_gettupleslot function (src/backend/executor/nodeWindowAgg.c)
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t52387psql -h localhost -U postgresBuilt from patchset v3 (message #3), July 27, 2026 at 07:20 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t52387_3 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t52387_3 && git checkout t52387_3Patchset v3 (message #3) is on t52387_3
Hi.
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).
The function "window_gettupleslot" can fail.
All other calls check the return, In this case it could not be different.
Fix by checking the return and reporting a message to the user,
in case of failure.
The error message, however, I'm not sure if it's ideal.
best regards,
Ranier Vilela
Attachments:
fix-api-misuse-function-window_gettupleslot.patchapplication/octet-stream; name=fix-api-misuse-function-window_gettupleslot.patchDownload+2-1
Ranier Vilela <ranier.vf@gmail.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 looks
to me like a failure should be interpreted as "row doesn't exist,
therefore it's not in frame".
What would be really useful is a test case that reaches this
condition. That would make it plain what to do.
regards, tom lane
Em dom., 5 de out. de 2025 às 13:05, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
Ranier Vilela <ranier.vf@gmail.com> writes:
Per Coverity.
CID 1635309: (#1 of 1): Unchecked return value (CHECKED_RETURN)
7. check_return: Calling window_gettupleslot without checking returnvalue
(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
Em seg., 6 de out. de 2025 às 08:33, Ranier Vilela <ranier.vf@gmail.com>
escreveu:
Em dom., 5 de out. de 2025 às 13:05, Tom Lane <tgl@sss.pgh.pa.us>
escreveu:Ranier Vilela <ranier.vf@gmail.com> writes:
Per Coverity.
CID 1635309: (#1 of 1): Unchecked return value (CHECKED_RETURN)
7. check_return: Calling window_gettupleslot without checking returnvalue
(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]/messages/by-id/20251002.211550.1475922457918078317.ishii@postgresql.org
I'll withdraw these patch.
best regards,
Ranier Vilela
[1]: /messages/by-id/20251002.211550.1475922457918078317.ishii@postgresql.org
/messages/by-id/20251002.211550.1475922457918078317.ishii@postgresql.org