Thread: Crash recovery after dropdb crash
I was experimenting with the crash recovery of server. So I simulated a crash in dropdb command.
After the crash recovery the server seems to be in inconsistent state. The pg_database still has the dropped database's information. But when I try to connect to that DB following error is seen:
FATAL: database "testdb" does not exist
DETAIL: The database subdirectory "base/xxxxx" is missing.
It seems this is know behavior, the code comment in dbcommands.d indicates that:
/*
* Force synchronous commit, thus minimizing the window between removal of
* the database files and commital of the transaction. If we crash before
* committing, we'll have a DB that's gone on disk but still there
* according to pg_database, which is not good.
*/
Is this a bug and needs a fix?
Regards,
Neha
Neha
I see another community thread that discusses similar issue.
There the inconsistent state is reached after a PITR. Couple of solutions have been
proposed in that thread for this, but no conclusion has been made.
Would like to understand if there is a reason for leaving this unresolved. Does it not
impact any usecases?
Regards,
Neha
Neha
On Wed, May 18, 2016 at 1:02 AM, neha khatri <nehakhatri5@gmail.com> wrote:
I was experimenting with the crash recovery of server. So I simulated a crash in dropdb command.After the crash recovery the server seems to be in inconsistent state. The pg_database still has the dropped database's information. But when I try to connect to that DB following error is seen:FATAL: database "testdb" does not existDETAIL: The database subdirectory "base/xxxxx" is missing.It seems this is know behavior, the code comment in dbcommands.d indicates that:/** Force synchronous commit, thus minimizing the window between removal of* the database files and commital of the transaction. If we crash before* committing, we'll have a DB that's gone on disk but still there* according to pg_database, which is not good.*/Is this a bug and needs a fix?Regards,
Neha