Maksim Milyutin

> I don't think that it can run the executor, but it can e.g. do index scan for get_variable_range or call plpgsql functions, but those have their own processing and...

> > >Now the planner can also call the planner itself, which is a problem since you will only keep the queryid from the last planner call during the whole...

> How will the collector know which nested level is active? The latest level (top of stack) is active, isn't it? It means the query with the last inserted queryId...

> If you store the stack in shared memory, you will also need to store an array of index to specify which level is valid, which seems like a waste....

Hi, @grin31 ! I suppose this issue was resolved in https://github.com/postgrespro/pg_wait_sampling/pull/31 . From your picture it might be concluded that collector process hangs holding its own lock, I suppose, while...

> Changing this value from "PROFILE_RESET" to "PROFILE_REQUEST" could cause deadlock: "collector" processed "PROFILE_RESET" query while client backend waits data from the "collector_mq" shared memory message queue. Not deadlock but...

> 1. deadlock (stuck, enter inconsistent state with denial of service, etc.) while processing script below > > > > psql -c "CREATE EXTENSION pg_wait_sampling" > > for j in...

@rzharkov could you make necessary changes - remove `LockRelease()` moving in `receive_array()` and `pg_wait_sampling_reset_profile()` functions? This moving is redundant as it doesn't protect `collector_hdr->request` shared variable but just is used...

> Consider the following interleaving: > > 1. S1 executed pg_wait_sampling_reset_profile and set `collector_hdr->request` to `PROFILE_RESET`. > > 2. S2 is executing receive_array. It acquires the queue lock, acquires and...

> I dropped the changes related to init_lock_tag from the patch It looked as harmless refactoring. I would accepted patch with this fix. > I dropped the changes related to...