Re: Improve pg_re_throw: check if sigjmp_buf is valid and report error - Mailing list pgsql-hackers

From Xing Guo
Subject Re: Improve pg_re_throw: check if sigjmp_buf is valid and report error
Date
Msg-id CACpMh+CqhwTWUU9GMvSqriXCr0y986=LQd03YiP6sP-3XAgMGw@mail.gmail.com
Whole thread Raw
In response to Re: Improve pg_re_throw: check if sigjmp_buf is valid and report error  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi

On Mon, Aug 19, 2024 at 10:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> We have had multiple instances of code "return"ing out of a PG_TRY,
> so I fully agree that some better way to detect that would be good.
> But maybe we ought to think about static analysis for that.

I have some static analysis scripts for detecting this kind of problem
(of mis-using PG_TRY). Not sure if my scripts are helpful here but I
would like to share them.

- A clang plugin for detecting unsafe control flow statements in
PG_TRY. https://github.com/higuoxing/clang-plugins/blob/main/lib/ReturnInPgTryBlockChecker.cpp
- Same as above, but in CodeQL[^1] script.
https://github.com/higuoxing/postgres.ql/blob/main/return-in-PG_TRY.ql
- A CodeQL script for detecting the missing of volatile qualifiers
(objects have been changed between the setjmp invocation and longjmp
call should be qualified with volatile).
https://github.com/higuoxing/postgres.ql/blob/main/volatile-in-PG_TRY.ql

Andres also has some compiler hacking to detect return statements in PG_TRY[^2].

[^1]: https://codeql.github.com/
[^2]: https://www.postgresql.org/message-id/20230113054900.b7onkvwtkrykeu3z%40awork3.anarazel.de



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: define PG_REPLSLOT_DIR
Next
From: Jelte Fennema-Nio
Date:
Subject: Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs