Re: Crash recovery after dropdb crash - Mailing list pgsql-novice

From neha khatri
Subject Re: Crash recovery after dropdb crash
Date
Msg-id CAFO0U+_oB1T7s1RYVybwc9YGkJ=rW=oD6sc-a0WSyRtujZbUNA@mail.gmail.com
Whole thread Raw
In response to Crash recovery after dropdb crash  (neha khatri <nehakhatri5@gmail.com>)
List pgsql-novice
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

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 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

pgsql-novice by date:

Previous
From: neha khatri
Date:
Subject: Crash recovery after dropdb crash
Next
From: Peter Crosbie
Date:
Subject: postgres 9.5 create function plpthon3u resets connections to server