From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Adding facility for injection points (or probe points?) for more advanced tests |
Date: | 2023-11-14 13:11:50 |
Message-ID: | 202311141311.v7gvjwrsubov@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
Good stuff here, I also have a bunch of bugfix commits that ended up not
having a test because of the need for a debugger or other interaction,
so let's move forward.
I think the docs (and the macro/function naming) describe things
backwards. In my mind, it is INJECTION_POINT_RUN() that creates the
injection point; then InjectionPointCreate() attaches something to it.
So I would rename the macro to just INJECTION_POINT() and the function
to InjectionPointAttach(). This way you're saying "attach function FN
from library L to the injection point P"; where P is an entity that is
being created by the INJECTION_POINT() call in the code.
You named the hash table InjectionPointHashByName, which seems weird.
Is there any *other* way to locate an injection point that is not by
name?
In this patch, injection points are instance-wide (because the hash
table is in shmem). As soon as you install a callback to one point,
that callback will be fired in every session. Maybe for some tests this
is OK (and in particular your TAP tests have them attached in one
->safe_psql call and then they hit a completely different session, which
wouldn't work if the attachments were process-local), but maybe one
would want them limited to some specific process. Maybe give an
optional PID so that if any other process hits that injection point,
nothing happens?
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"La rebeldía es la virtud original del hombre" (Arthur Schopenhauer)
From | Date | Subject | |
---|---|---|---|
Next Message | Nikita Malakhov | 2023-11-14 13:12:20 | Re: RFC: Pluggable TOAST |
Previous Message | torikoshia | 2023-11-14 13:02:32 | Re: Add new option 'all' to pg_stat_reset_shared() |