Hi, On 2023-05-09 15:41:36 +1200, Thomas Munro wrote: > +# FIXME: It'd be good to test the actual interruption path. But it's not > +# immediately obvious how. > > I wonder if there is some way to incorporate something based on > SIGSTOP signals into the test, but I don't know how to do it on > Windows and maybe that's a bit weird anyway. For a non-OS-specific > way to do it, I was wondering about having a test module function that > has a wait loop that accepts ^C but deliberately ignores > ProcSignalBarrier, and leaving that running in a background psql for a > similar effect?
I found a way to test it reliably, albeit partially. However, I'm not sure where to do so / if it's worth doing so. The problem occurs once remove_dbtablespaces() starts working. The fix does a heap_inplace_update() before that. So to reproduce the problem one session can lock pg_tablespace, another can drop a database. Then the second session can be cancelled by the first. Waiting for locks to be acquired etc is somewhat cumbersome in a tap test. It'd be easier in an isolation test. But I don't think we want to do this as part of the normal isolation schedule? So just open coding it in a tap test seems to be the best way? Is it worth doing? Greetings, Andres Freund
