From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: DROP DATABASE is interruptible |
Date: | 2023-06-22 02:38:17 |
Message-ID: | 20230622023817.tlfzgckaugbuxuek@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiro Ikeda | 2023-06-22 03:06:04 | Re: Support to define custom wait events for extensions |
Previous Message | Kyotaro Horiguchi | 2023-06-22 01:48:54 | Re: bgwriter doesn't flush WAL stats |