Sorry for not responding to this thread for a long time and a huge thank
you for pushing it forward!
Best Regards,
Xing
On Fri, May 5, 2023 at 7:42 AM Nathan Bossart
wrote:
> On Thu, May 04, 2023 at 08:39:03AM -0400, Tom Lane wrote:
> > Hmm, I'm not sure why PLy_trigger_build_args's
On Thu, May 04, 2023 at 08:39:03AM -0400, Tom Lane wrote:
> Hmm, I'm not sure why PLy_trigger_build_args's pltargs needs to
> gain a "volatile" here? LGTM otherwise.
I removed that new "volatile" marker before committing. I was trying to
future-proof a bit and follow elog.h's recommendation to
Nathan Bossart writes:
> Gah, right after I sent that, I realized we can remove one more volatile
> marker. Sorry for the noise.
Hmm, I'm not sure why PLy_trigger_build_args's pltargs needs to
gain a "volatile" here? LGTM otherwise.
regards, tom lane
On Wed, May 03, 2023 at 09:54:13PM -0700, Nathan Bossart wrote:
> Here's a new patch that removes the volatile marker from pltdata.
Gah, right after I sent that, I realized we can remove one more volatile
marker. Sorry for the noise.
--
Nathan Bossart
Amazon Web Services:
On Wed, May 03, 2023 at 01:58:38PM -0700, Nathan Bossart wrote:
> With this change, pltdata isn't modified in the PG_TRY section, and the
> only modification of pltargs happens after all elogs. It might be worth
> keeping pltargs volatile in case someone decides to add an elog() in the
> future,
On Wed, May 03, 2023 at 04:33:32PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> Here's a new version of the patch. Besides adding comments and a commit
>> message, I made sure to decrement the reference count for pltargs in the
>> PG_CATCH block (which means that pltargs likely needs to be
Nathan Bossart writes:
> Here's a new version of the patch. Besides adding comments and a commit
> message, I made sure to decrement the reference count for pltargs in the
> PG_CATCH block (which means that pltargs likely needs to be volatile).
Hmm, actually I think these changes should allow
Here's a new version of the patch. Besides adding comments and a commit
message, I made sure to decrement the reference count for pltargs in the
PG_CATCH block (which means that pltargs likely needs to be volatile). I'm
not too wild about moving the chunk of code for pltargs like this, but I
On Thu, Jan 19, 2023 at 05:07:11PM -0800, Andres Freund wrote:
> I'm somewhat dubious about allowing to return inside PG_CATCH, even if it's
> safe today.
+1. Unless there are known use-cases, IMHO it'd be better to restrict it
to prevent future compatibility breaks as PG_TRY evolves.
--
Hi,
On 2023-01-16 10:29:03 -0500, Tom Lane wrote:
> Xing Guo writes:
> > Are there any unsafe codes in pltcl.c? The return statement is in the
> > PG_CATCH() block, I think the exception stack has been recovered in
> > PG_CATCH block so the return statement in PG_CATCH block should be ok?
>
>
On Mon, Jan 16, 2023 at 11:29 PM Tom Lane wrote:
> Xing Guo writes:
> > Are there any unsafe codes in pltcl.c? The return statement is in the
> > PG_CATCH() block, I think the exception stack has been recovered in
> > PG_CATCH block so the return statement in PG_CATCH block should be ok?
>
>
Xing Guo writes:
> Are there any unsafe codes in pltcl.c? The return statement is in the
> PG_CATCH() block, I think the exception stack has been recovered in
> PG_CATCH block so the return statement in PG_CATCH block should be ok?
Yes, the stack has already been unwound at the start of a
Hi,
I revised my patch, added the missing one that Nathan mentioned.
Are there any unsafe codes in pltcl.c? The return statement is in the
PG_CATCH() block, I think the exception stack has been recovered in
PG_CATCH block so the return statement in PG_CATCH block should be ok?
```
PG_TRY();
{
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
Hi Nathan.
On 1/13/23, Nathan Bossart wrote:
> On Thu, Jan 12, 2023 at 11:19:29PM +0800, Xing Guo wrote:
>> I was running static analyser against PostgreSQL and found there're 2
>> return statements in PL/Python module which is not safe. Patch is
>> attached.
>
> Is the problem that
Hi,
On 2023-01-12 21:49:00 -0800, Andres Freund wrote:
> Clearly this would need a bunch more work, but it seems promising? I think
> there'd be other uses than this.
>
> I briefly tried to use it for spinlocks. Mostly works and detects things like
> returning with a spinlock held. But it does
Hi,
On 2023-01-12 10:44:33 -0800, Nathan Bossart wrote:
> On Thu, Jan 12, 2023 at 11:19:29PM +0800, Xing Guo wrote:
> > @@ -690,12 +690,12 @@ PLy_trigger_build_args(FunctionCallInfo fcinfo,
> > PLyProcedure *proc, HeapTuple *r
> > PyObject *volatile pltdata = NULL;
> > char
On Thu, Jan 12, 2023 at 10:44:33AM -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.
Note also:
src/pl/tcl/pltcl.c- * PG_CATCH();
src/pl/tcl/pltcl.c- * {
src/pl/tcl/pltcl.c- *
On Thu, Jan 12, 2023 at 11:19:29PM +0800, Xing Guo wrote:
> I was running static analyser against PostgreSQL and found there're 2
> return statements in PL/Python module which is not safe. Patch is
> attached.
Is the problem that PG_exception_stack and error_context_stack aren't
properly reset?
Hi hackers,
I was running static analyser against PostgreSQL and found there're 2
return statements in PL/Python module which is not safe. Patch is
attached.
--
Best Regards,
Xing
diff --git a/src/pl/plpython/plpy_exec.c b/src/pl/plpython/plpy_exec.c
index 923703535a..c0e4a81283 100644
---
20 matches
Mail list logo
