On Thu, Sep 7, 2023, at 1:09 PM, torikoshia wrote:
> On 2023-09-06 11:17, James Coleman wrote:
> It seems that we can know what queries were running from the stack
> traces you shared.
> As described above, I suspect a lock which was acquired prior to
> ProcessLogQueryPlanInterrupt() caused the issue.
> I will try a little more to see if I can devise a way to create the same
> situation.
Hi,
I have explored this patch and, by and large, agree with the code. But some questions I want to discuss:
1. Maybe add a hook to give a chance for extensions, like pg_query_state, to do their job?
2. In this implementation, ProcessInterrupts does a lot of work during the explain creation: memory allocations, pass
throughthe plan, systables locks, syscache access, etc. I guess it can change the semantic meaning of 'safe place'
whereCHECK_FOR_INTERRUPTS can be called - I can imagine a SELECT query, which would call a stored procedure, which
executessome DDL and acquires row exclusive lock at the time of interruption. So, in my mind, it is too unpredictable
tomake the explain in the place of interruption processing. Maybe it is better to think about some hook at the end of
ExecProcNode,where a pending explain could be created?
Also, I suggest minor code change with the diff in attachment.
--
Regards,
Andrei Lepikhov