Re: DROP DATABASE is interruptible

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: DROP DATABASE is interruptible
Дата
Msg-id CA+hUKGLvMHb9p-SVgu4+_EQ+Lj2YeDN6qDtSj3sAKr30qMA6vw@mail.gmail.com
обсуждение исходный текст
Ответ на DROP DATABASE is interruptible  (Andres Freund <andres@anarazel.de>)
Ответы Re: DROP DATABASE is interruptible  (Thomas Munro <thomas.munro@gmail.com>)
Re: DROP DATABASE is interruptible  (Andres Freund <andres@anarazel.de>)
Re: DROP DATABASE is interruptible  (Andres Freund <andres@anarazel.de>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: WAL Insertion Lock Improvements
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: DROP DATABASE is interruptible