Re: DROP DATABASE is interruptible

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: DROP DATABASE is interruptible
Date: 2023-05-09 03:41:36
Message-ID: CA+hUKGLvMHb9p-SVgu4+_EQ+Lj2YeDN6qDtSj3sAKr30qMA6vw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I tried out the patch you posted over at [1]. For those wanting an
easy way to test it, or test the buggy behaviour in master without
this patch, you can simply kill -STOP the checkpointer, so that DROP
DATABASE hangs in RequestCheckpoint() (or you could SIGSTOP any other
backend so it hangs in the barrier thing instead), and then you can
just press ^C like this:

postgres=# create database db2;
CREATE DATABASE
postgres=# drop database db2;
^CCancel request sent
ERROR: canceling statement due to user request

After that you get:

$ psql db2
psql: error: connection to server on socket "/tmp/.s.PGSQL.5432"
failed: FATAL: database "db2" is invalid
DETAIL: Use DROP DATABASE to drop invalid databases

I suppose it should be a HINT?

+# 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?

Not sure why the test is under src/test/recovery.

While a database exists in this state, we get periodic autovacuum
noise, which I guess we should actually skip? I suppose someone might
eventually wonder if autovacuum could complete the drop, but it seems
a bit of a sudden weird leap in duties and might be confusing (perhaps
it'd make more sense if 'invalid because creating' and 'invalid
because dropping' were distinguished).

2023-05-09 15:24:10.860 NZST [523191] FATAL: database "db2" is invalid
2023-05-09 15:24:10.860 NZST [523191] DETAIL: Use DROP DATABASE to
drop invalid databases
2023-05-09 15:25:10.883 NZST [523279] FATAL: database "db2" is invalid
2023-05-09 15:25:10.883 NZST [523279] DETAIL: Use DROP DATABASE to
drop invalid databases
2023-05-09 15:26:10.899 NZST [523361] FATAL: database "db2" is invalid
2023-05-09 15:26:10.899 NZST [523361] DETAIL: Use DROP DATABASE to
drop invalid databases
2023-05-09 15:27:10.919 NZST [523408] FATAL: database "db2" is invalid
2023-05-09 15:27:10.919 NZST [523408] DETAIL: Use DROP DATABASE to
drop invalid databases
2023-05-09 15:28:10.938 NZST [523456] FATAL: database "db2" is invalid
2023-05-09 15:28:10.938 NZST [523456] DETAIL: Use DROP DATABASE to
drop invalid databases

[1] https://www.postgresql.org/message-id/20230509013255.fjrlpitnj3ltur76%40awork3.anarazel.de

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2023-05-09 03:50:01 Re: DROP DATABASE is interruptible
Previous Message Michael Paquier 2023-05-09 03:32:07 Re: WAL Insertion Lock Improvements