Hi,
> Fixed all that, adjusted a few comments, then applied the result.
>
Thank you for making the fixes and committing the patch.
-Rahila Syed
On Sun, Nov 09, 2025 at 08:35:55AM +0900, Michael Paquier wrote:
> Yeah. What you are doing would be enough on simplicity ground. The
> test added is also fine enough, it's safe to run even under an
> installcheck. So LGTM to use a minimal implementation.
The patch had a one problem other than
On Fri, Nov 07, 2025 at 05:39:57PM +0530, Rahila Syed wrote:
> OK, it makes sense to leave it out of this function for now. Since
> pgstat_create_inj() currently only tracks the number of runs, it also
> depends on any callback using the appropriate pgstat_report_* API
> from the injection_point mo
Hi,
Thank you for your review.
>
> + if (injection_point_local)
> + {
> + condition.type = INJ_CONDITION_PID;
> + condition.pid = MyProcPid;
> + }
>
> Hmm. Is there a point in registering a condition that's linked to
> the shared library injection_po
On Tue, Nov 04, 2025 at 02:17:44PM +0530, Rahila Syed wrote:
> PFA a rebased patch that contains the test.
> The tests use the newly added SQL function to attach the injection_notice
> function to an injection point
+ if (injection_point_local)
+ {
+ condition.type = INJ_
Hi Mihail,
Thank you for looking into this thread.
>
> I thought it may help me to implement some kind of notice+wait
> required for [1] in order to stabilize the tests.
>
> Is it possible to do something like this in the attached function?
>
> RAISE NOTICE 'going to wait';
> SELECT injec
Hello!
I thought it may help me to implement some kind of notice+wait
required for [1] in order to stabilize the tests.
Is it possible to do something like this in the attached function?
RAISE NOTICE 'going to wait';
SELECT injection_points_run(some_point_with_wait"); -- wait called
insi
Hi,
> How about a simpler injection_points_attach(point_name text, func
> text, module text) with a second SQL function, but a different number
> of arguments? Using a new hardcoded action for this purpose is
> confusing as your point is to introduce a SQL wrapper on top of
> InjectionPointAttac
On Tue, Oct 28, 2025 at 06:11:25PM +0530, Rahila Syed wrote:
> I would like to propose providing a sql interface to link a
> user-defined function to an injection point.
> Currently, if a user wants an injection point to invoke a custom
> function, they must first define an SQL
> function that atta
