> On 3 Mar 2021, at 23:19, Thomas Munro <thomas.mu...@gmail.com> wrote: > On Thu, Mar 4, 2021 at 4:18 AM Daniel Gustafsson <dan...@yesql.se> wrote:
>> Since there is no way to get make the first destroy_tablespace_directories >> call >> fail on purpose in testing, the assertion coverage may have limited use >> though? > > There is: all you have to do is drop a table, and then drop the > tablespace that held it without a checkpoint in between. Of course, that makes a lot of sense. > One thing I am pretty sure of is that it's never OK to > wait for a ProcSignalBarrier when you're not interruptible; Agreed. > for one thing, you won't process the request yourself (self deadlock) and for > another, it would be hypocritical of you to expect others to process > interrupts > when you can't (interprocess deadlock); perhaps there should be an assertion > about that, but it's pretty obvious if you screw that up: it hangs. An assertion for interrupts not being held off doesn't seem like a terrible idea, if only to document the intent of the code for readers. > That's why I release and reacquire that LWLock. But does that break some > logic? One clear change to current behavior is naturally that a concurrent TablespaceCreateDbspace can happen while barrier absorption is performed. Given where we are that might not be a problem, but I don't have enough caffeine at the moment to conclude anything there. Testing nu inducing concurent calls while absorption was stalled didn't trigger anything, but I'm sure I didn't test every scenario. Do you see anything off the cuff? -- Daniel Gustafsson https://vmware.com/
