On 3/26/25 22:57, Rafael Thofehrn Castro wrote:
So implementation was done based on transaction nested level. Cleanup is
only
performed when AbortSubTransaction() is called in the same transaction
nested
level as the one where the query is running. This covers both PL/pgSQL
exception
blocks and savepoints.
Thanks for your efforts!
Let me provide an alternative view of your code.
Postgres has a massive gap between the start of the execution and the
end. All the stuff that happens at that time can't be discovered. That's
sad. If you add a new hook into the ExecuteNode (it may be designed as a
pointer in the PlanState to affect only necessary nodes), you may push
the code out of the core and give other extensions additional tools.
I see your reasoning here [1], but I think with the commit 4fd02bf7cf9,
it should be revised.
As I see after reviewing your code, to design it as an extension, some
parallel query execution stuff needs to be exported, and Instrumentation
needs to be changed a little. For example, with progressive explain we
have a new node state - 'not visited yet' that is different from 'not
executed'.
What is the purpose of a new hook from a broad perspective? I designed
at least two features with such a hook in the Postgres fork: 1)
real-time execution statistics and 2) query interruption on the
arbitrary trigger (planning error detected, a signal arrived, too much
temp memory allocated, etc.). I am not sure if it would be interesting
for the community, but when a query is executed for more than one
minute, I certainly want to control what is happening and have some
tools except query abortion.
The benefit of such an approach is that it is doable to change the
Instrumentation, add a hook now, and develop this extension without a
rush until it is stable - I think at least the case of parallel
execution may be enhanced.
[1]
https://www.postgresql.org/message-id/CAG0ozMrtK_u8Uf5KNZUmRNuMphV5tnC5DEhRBNRGK%2BK4L506xw%40mail.gmail.com
--
regards, Andrei Lepikhov
