On Thu, Jan 12, 2023 at 09:49:00PM -0800, Andres Freund wrote: > On 2023-01-12 10:44:33 -0800, Nathan Bossart wrote: >> There's another "return" later on in this PG_TRY block. I wonder if it's >> possible to detect this sort of thing at compile time. > > Clang provides some annotations that allow to detect this kind of thing. I > hacked up a test for this, and it finds quite a bit of prolematic > code.
Nice! > plpython is, uh, not being good? But also in plperl, pltcl. Yikes. > ../../../../home/andres/src/postgresql/src/pl/tcl/pltcl.c:1830:1: warning: > no_returns_in_pg_try 'no_returns_handle' is not held on every path through > here [-Wthread-safety-analysis] > } > ^ > ../../../../home/andres/src/postgresql/src/pl/tcl/pltcl.c:1809:2: note: > no_returns_in_pg_try acquired here > PG_CATCH(); > ^ > ../../../../home/andres/src/postgresql/src/include/utils/elog.h:433:7: note: > expanded from macro 'PG_CATCH' > no_returns_start(no_returns_handle##__VA_ARGS__) > ^ > > Not perfect digestible, but also not too bad. I pushed the > no_returns_start()/no_returns_stop() calls into all the PG_TRY related macros, > because that causes the warning to point to block that the problem is > in. E.g. above the first warning points to PG_TRY, the second to > PG_CATCH. It'd work to just put it into PG_TRY and PG_END_TRY. This seems roughly as digestible as the pg_prevent_errno_in_scope stuff. However, on my macOS machine with clang 14.0.0, the messages say "mutex" instead of "no_returns_in_pg_try," which is unfortunate since that's the part that would clue me into what the problem is. I suppose it'd be easy enough to figure out after a grep or two, though. > Clearly this would need a bunch more work, but it seems promising? I think > there'd be other uses than this. +1 -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
