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

  1. pg_dump: tests: Correct test condition for invalid databases

  2. Handle DROP DATABASE getting interrupted