Re: DROP DATABASE is interruptible - Mailing list pgsql-hackers

From Andres Freund
Subject Re: DROP DATABASE is interruptible
Date
Msg-id 20230622023817.tlfzgckaugbuxuek@awork3.anarazel.de
Whole thread Raw
In response to Re: DROP DATABASE is interruptible  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: bgwriter doesn't flush WAL stats
Next
From: Masahiro Ikeda
Date:
Subject: Re: Support to define custom wait events for extensions