Re: Crash recovery after dropdb crash

I see another community thread that discusses similar issue.
http://www.postgresql.org/message-id/20141125160629.GC21475@msg.df7cb.de

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(at)gmail(dot)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
>