Re: plpgsq_plugin's stmt_end() is not called when an error is caught - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: plpgsq_plugin's stmt_end() is not called when an error is caught
Date
Msg-id CAFj8pRAreDtH-VWDSu2d4-JNqBK76NDuQLD0RLKX3GF5GJ87cA@mail.gmail.com
Whole thread Raw
In response to Re: plpgsq_plugin's stmt_end() is not called when an error is caught  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers


čt 15. 12. 2022 v 9:34 odesílatel Kyotaro Horiguchi <horikyota.ntt@gmail.com> napsal:
At Thu, 15 Dec 2022 09:03:12 +0100, Pavel Stehule <pavel.stehule@gmail.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

pgsql-hackers by date:

Previous
From: "Drouvot, Bertrand"
Date:
Subject: Re: Minimal logical decoding on standbys
Next
From: Daniel Gustafsson
Date:
Subject: Re: Raising the SCRAM iteration count