Re: enhancing plpgsql debug api - hooks on statements errors and function errors

From: Kirk Wolak <wolakk(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: enhancing plpgsql debug api - hooks on statements errors and function errors
Date: 2023-05-10 04:11:20
Message-ID: CACLU5mS15U7ch3ZkQ4rc0Mrw-1xgX6fPRKeX28wP7xtg=v7mGg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Apr 25, 2023 at 11:33 AM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
wrote:

> Hi
> út 25. 4. 2023 v 10:27 odesílatel Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> napsal:
>
>> Hi
>>
>> When I implemented profiler and coverage check to plpgsql_check I had to
>> write a lot of hard maintaining code related to corect finishing some
>> operations (counter incrementing) usually executed by stmt_end and func_end
>> hooks. It is based on the fmgr hook and its own statement call stack. Can
>> be nice if I can throw this code and use some nice buildin API.
>>
>> Can we enhance dbg API with two hooks stmt_end_err func_end_err ?
>>
>> These hooks can be called from exception handlers before re raising.
>>
>> Or we can define new hooks like executor hooks - stmt_exec and func_exec.
>> In custom hooks the exception can be catched.
>>
>> What do you think about this proposal?
>>
>> +1. I believe I bumped into a few of these use cases with plpgsql_check
(special handling for security definer and exception handling).
My cursory review of the patch file is that despite the movement of the
code, it feels pretty straight forward.

The 7% overhead appears in a "tight loop", so it's probably really
overstated. I will see if I can apply this and do a more realistic test.
[I have a procedure that takes ~2hrs to process a lot of data, I would be
curious to see this impact and report back]

> I did quick and ugly benchmark on worst case
>
> CREATE OR REPLACE FUNCTION public.speedtest(i integer)
> RETURNS void
> LANGUAGE plpgsql
> IMMUTABLE
> AS $function$
> declare c int = 0;
> begin
> while c < i
> loop
> c := c + 1;
> end loop;
> raise notice '%', c;
> end;
> $function$
>
> and is possible to write some code (see ugly patch) without any
> performance impacts if the hooks are not used. When hooks are active, then
> there is 7% performance lost. It is not nice - but this is the worst case.
> The impact on real code should be significantly lower
>
> Regards
>
> Pavel
>
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2023-05-10 04:58:22 Re: psql tests hangs
Previous Message Thomas Munro 2023-05-10 03:11:20 Unlinking Parallel Hash Join inner batch files sooner