Re: Crash recovery after dropdb crash
| От | neha khatri |
|---|---|
| Тема | Re: Crash recovery after dropdb crash |
| Дата | |
| Msg-id | CAFO0U+_oB1T7s1RYVybwc9YGkJ=rW=oD6sc-a0WSyRtujZbUNA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Crash recovery after dropdb crash (neha khatri <nehakhatri5@gmail.com>) |
| Список | 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
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
В списке pgsql-novice по дате отправления: