DROP DATABASE is interruptible
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: pgsql-hackers@postgresql.org
Date: 2023-03-14T17:45:21Z
Lists: pgsql-hackers
Hi, Unfortunately DROP DATABASE does not hold interrupt over its crucial steps. If you e.g. set a breakpoint on DropDatabaseBuffers() and then do a signal SIGINT, we'll process that interrupt before the transaction commits. A later connect to that database ends with: 2023-03-14 10:22:24.443 PDT [3439153][client backend][3/2:0][[unknown]] PANIC: could not open critical system index 2662 It's not entirely obvious how to fix this. We can't just hold interrupts for the whole transaction - for one, we hang if we do so, because it prevents ourselves from absorbing our own barrier: /* Close all smgr fds in all backends. */ WaitForProcSignalBarrier(EmitProcSignalBarrier(PROCSIGNAL_BARRIER_SMGRRELEASE)); ISTM that at the very least dropdb() needs to internally commit *before* dropping buffers - after that point the database is corrupt. Greetings, Andres Freund
Commits
-
pg_dump: tests: Correct test condition for invalid databases
- 881defde944c 16.1 landed
- 6a3b19bbefd7 11.22 landed
- fd7a114dbb4e 12.17 landed
- d1c76fdec375 13.13 landed
- 4dfb610822d5 14.10 landed
- 9dc3c5472ed9 15.5 landed
- 849d367ff9a2 17.0 landed
-
Handle DROP DATABASE getting interrupted
- f66403749df7 15.4 landed
- 1c38e7ae17b6 11.21 landed
- 034a9fcd2bb8 12.16 landed
- 81ce000067e3 13.12 landed
- d11efe830385 14.9 landed
- a4b4cc1d60f7 16.0 landed
- c66a7d75e652 17.0 landed