On Sun, May 8, 2022 at 7:30 PM Thomas Munro <thomas.mu...@gmail.com> wrote: > Simple idea: how about logging the PID of processes that block > progress for too long? In the attached, I arbitrarily picked 5 > seconds as the wait time between LOG messages. Also, DEBUG1 messages > let you see the processing speed on eg build farm animals. Thoughts? > > To test this, kill -STOP a random backend, and then try an ALTER > DATABASE SET TABLESPACE in another backend. Example output: > > DEBUG: waiting for all backends to process ProcSignalBarrier generation 1 > LOG: still waiting for pid 1651417 to accept ProcSignalBarrier > STATEMENT: alter database mydb set tablespace ts1; > LOG: still waiting for pid 1651417 to accept ProcSignalBarrier > STATEMENT: alter database mydb set tablespace ts1; > LOG: still waiting for pid 1651417 to accept ProcSignalBarrier > STATEMENT: alter database mydb set tablespace ts1; > LOG: still waiting for pid 1651417 to accept ProcSignalBarrier > STATEMENT: alter database mydb set tablespace ts1;
This is a very good idea. > Another thought is that it might be nice to be able to test with a > dummy PSB that doesn't actually do anything. You could use it to see > how fast your system processes it, while doing various other things, > and to find/debug problems in other code that fails to handle > interrupts correctly. Here's an attempt at that. I guess it could go > into a src/test/modules/something instead of core, but on the other > hand the PSB itself has to be in core anyway, so maybe not. Thoughts? > No documentation yet, just seeing if people think this is worth > having... better names/ideas welcome. I did this at one point, but I wasn't convinced it was going to find enough bugs to be worth committing. It's OK if you're convinced of things that didn't convince me, though. -- Robert Haas EDB: http://www.enterprisedb.com
