pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Nathan Bossart <nathandbossart@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Xing Guo <higuoxing@gmail.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: PL/Python: Fix return in the middle of PG_TRY() block.
Date: Fri, 13 Jan 2023 10:03:35 -0800
Message-ID: <20230113180335.GA2160040@nathanxps13> (raw)
In-Reply-To: <20230113054900.b7onkvwtkrykeu3z@awork3.anarazel.de>
References: <CACpMh+CMsGMRKFzFMm3bYTzQmMU5nfEEoEDU2apJcc4hid36AQ@mail.gmail.com>
	<20230112184433.GA2104952@nathanxps13>
	<20230113054900.b7onkvwtkrykeu3z@awork3.anarazel.de>

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





view thread (20+ messages)  latest in thread

Message-ID: <20230113180335.GA2160040@nathanxps13>
Permalink:  ../20230113180335.GA2160040@nathanxps13/
Also on:    postgresql.org/message-id/20230113180335.GA2160040@nathanxps13

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: nathandbossart@gmail.com, andres@anarazel.de, higuoxing@gmail.com
  Subject: Re: PL/Python: Fix return in the middle of PG_TRY() block.
  In-Reply-To: <20230113180335.GA2160040@nathanxps13>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox