mirror of
https://github.com/postgres/postgres.git
synced 2026-03-13 22:28:01 -04:00
81ce000067
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 |
||
|---|---|---|
| .. | ||
| 010_clusterdb.pl | ||
| 011_clusterdb_all.pl | ||
| 020_createdb.pl | ||
| 040_createuser.pl | ||
| 050_dropdb.pl | ||
| 070_dropuser.pl | ||
| 080_pg_isready.pl | ||
| 090_reindexdb.pl | ||
| 091_reindexdb_all.pl | ||
| 100_vacuumdb.pl | ||
| 101_vacuumdb_all.pl | ||
| 102_vacuumdb_stages.pl | ||
| 200_connstr.pl | ||