diff options
| author | Andres Freund <andres@anarazel.de> | 2023-07-13 13:03:31 -0700 |
|---|---|---|
| committer | Andres Freund <andres@anarazel.de> | 2023-07-13 13:04:45 -0700 |
| commit | f66403749df744be60f45d20cace48cbc030b804 (patch) | |
| tree | 70834052d6657fbae06cc5f0a58733f73522da29 /src/backend/commands/vacuum.c | |
| parent | 82e97b864004810db2d335cf26117f7f1c2ff435 (diff) | |
| download | postgresql-f66403749df744be60f45d20cace48cbc030b804.tar.gz postgresql-f66403749df744be60f45d20cace48cbc030b804.zip | |
Handle DROP DATABASE getting interrupted
Until now, when DROP DATABASE got interrupted in the wrong moment, the removal
of the pg_database row would also roll back, even though some irreversible
steps have already been taken. E.g. DropDatabaseBuffers() might have thrown
out dirty buffers, or files could have been unlinked. But we continued to
allow connections to such a corrupted database.
To fix this, mark databases invalid with an in-place update, just before
starting to perform irreversible steps. As we can't add a new column in the
back branches, we use pg_database.datconnlimit = -2 for this purpose.
An invalid database cannot be connected to anymore, but can still be
dropped.
Unfortunately we can't easily add output to psql's \l to indicate that some
database is invalid, it doesn't fit in any of the existing columns.
Add tests verifying that a interrupted DROP DATABASE is handled correctly in
the backend and in various tools.
Reported-by: Evgeny Morozov <postgresql3@realityexists.net>
Author: Andres Freund <andres@anarazel.de>
Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
Reviewed-by: Thomas Munro <thomas.munro@gmail.com>
Discussion: https://postgr.es/m/20230509004637.cgvmfwrbht7xm7p6@awork3.anarazel.de
Discussion: https://postgr.es/m/20230314174521.74jl6ffqsee5mtug@awork3.anarazel.de
Backpatch: 11-, bug present in all supported versions
Diffstat (limited to 'src/backend/commands/vacuum.c')
| -rw-r--r-- | src/backend/commands/vacuum.c | 14 |
1 files changed, 14 insertions, 0 deletions
diff --git a/src/backend/commands/vacuum.c b/src/backend/commands/vacuum.c index fca5b6c855d..75b0ca95347 100644 --- a/src/backend/commands/vacuum.c +++ b/src/backend/commands/vacuum.c @@ -1750,6 +1750,20 @@ vac_truncate_clog(TransactionId frozenXID, Assert(MultiXactIdIsValid(datminmxid)); /* + * If database is in the process of getting dropped, or has been + * interrupted while doing so, no connections to it are possible + * anymore. Therefore we don't need to take it into account here. + * Which is good, because it can't be processed by autovacuum either. + */ + if (database_is_invalid_form((Form_pg_database) dbform)) + { + elog(DEBUG2, + "skipping invalid database \"%s\" while computing relfrozenxid", + NameStr(dbform->datname)); + continue; + } + + /* * If things are working properly, no database should have a * datfrozenxid or datminmxid that is "in the future". However, such * cases have been known to arise due to bugs in pg_upgrade. If we |