Re: plpgsq_plugin's stmt_end() is not called when an error is caught

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: sawada(dot)mshk(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: plpgsq_plugin's stmt_end() is not called when an error is caught
Date: 2022-12-15 11:07:19
Message-ID: CAFj8pRAreDtH-VWDSu2d4-JNqBK76NDuQLD0RLKX3GF5GJ87cA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

čt 15. 12. 2022 v 9:34 odesílatel Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
napsal:

> At Thu, 15 Dec 2022 09:03:12 +0100, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote in
> > I found some solution based by using fmgr hook
> >
> >
> https://github.com/okbob/plpgsql_check/commit/9a17e97354a48913de5219048ee3be6f8460bae9
>
> Oh! Thanks for the pointer, will look into that.
>
> By the way, It seems to me that the tool is using
> RegisterResourceReleaseCallback to reset the function nest level. But
> since there's a case where the mechanism doesn't work, I suspect that
> the callback can be missed in some cases of error return, which seems
> to be a bug if it is true..
>
> # I haven't confirmed that behavior by myself, though.
>

it should be executed

/*
* Register or deregister callback functions for resource cleanup
*
* These functions are intended for use by dynamically loaded modules.
* For built-in modules we generally just hardwire the appropriate calls.
*
* Note that the callback occurs post-commit or post-abort, so the callback
* functions can only do noncritical cleanup.
*/
void
RegisterResourceReleaseCallback(ResourceReleaseCallback callback, void *arg)
{

but it is based on resource owner, so timing can be different than you
expect

Regards

Pavel

>
> regards.
>
> --
> Kyotaro Horiguchi
> NTT Open Source Software Center
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2022-12-15 11:09:01 Re: Raising the SCRAM iteration count
Previous Message Drouvot, Bertrand 2022-12-15 10:31:42 Re: Minimal logical decoding on standbys