Re: Fix DROP TABLESPACE on Windows with ProcSignalBarrier?

> On 3 Mar 2021, at 23:19, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Thu, Mar 4, 2021 at 4:18 AM Daniel Gustafsson <daniel(at)yesql(dot)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/