Re: DROP DATABASE is interruptible

Hi,

On 2023-06-21 12:02:04 -0700, Andres Freund wrote:
> I'm hacking on this bugfix again, thanks to Evgeny's reminder on the other
> thread [1].
> 
> 
> I've been adding checks for partiall-dropped databases to the following places
> so far:
> - vac_truncate_clog(), as autovacuum can't process it anymore. Otherwise a
>   partially dropped database could easily lead to shutdown-due-to-wraparound.
> - get_database_list() - so autovacuum workers don't error out when connecting
> - template database used by CREATE DATABASE
> - pg_dumpall, so we don't try to connect to the database
> - vacuumdb, clusterdb, reindexdb, same

Also pg_amcheck.


> It's somewhat annoying that there is no shared place for the relevant query
> for the client-side cases.

Still the case, I looked around, and it doesn't look we do anything smart
anywhere :/


> I haven't yet added checks to pg_upgrade, even though that's clearly
> needed. I'm waffling a bit between erroring out and just ignoring the
> database? pg_upgrade already fails when datallowconn is set "wrongly", see
> check_proper_datallowconn().  Any opinions?

There don't need to be explict checks, because pg_upgrade will fail, because
it connects to every database. Obviously the error could be nicer, but it
seems ok for something hopefully very rare. I did add a test ensuring that the
behaviour is caught.

It's somewhat odd that pg_upgrade prints errors on stdout...


> I'm not sure what should be done for psql. It's probably not a good idea to
> change tab completion, that'd just make it appear the database is gone. But \l
> could probably show dropped databases more prominently?

I have not done that. I wonder if this is something that should be done in the
back branches?

Greetings,

Andres Freund