Postgres Pro
Downloads
Home   >   mailing lists

Re: BUG #15589: Due to missing wal, restore ends prematurely andopens database for read/write - Mailing list pgsql-bugs

From Jeff Janes
Subject Re: BUG #15589: Due to missing wal, restore ends prematurely andopens database for read/write
Date
Msg-id CAMkU=1ym=UYLVS37NNSE547Uw0_xPJUuBmyZPqEHARd=Un6eiA@mail.gmail.com
Whole thread Raw
In response to BUG #15589: Due to missing wal,restore ends prematurely and opens database for read/write  (PG Bug reporting form <noreply@postgresql.org>)
Responses Re: BUG #15589: Due to missing wal, restore ends prematurely andopens database for read/write  (leif@lako.no)
Re: BUG #15589: Due to missing wal, restore ends prematurely andopens database for read/write  (leif@lako.no)
List pgsql-bugs
Tree view
On Fri, Jan 11, 2019 at 4:08 AM PG Bug reporting form <noreply@postgresql.org> wrote:

PostgreSQL should have paused recovery also on the first scenario. Then I
could have added missing wal and continued with restore.

I agree with you that something here is not very user friendly.  But the counter argument is that you should not be hiding WAL files from the system in the first place.  Once it is told that the file doesn't exist, it doesn't make sense to pause because non-existence is usually permanent, so there is nothing to be done after a pause.  Or in other words, the pause feature is to let you change your mind about what time point you want to recover to (moving it only forward), not to let you change your mind about what WAL files exist in the first place.  So I don't think this is a bug, but perhaps there is room for improvement.

At the least, I think we should log an explicit WARNING if the WAL stream ends before the specified PIT is reached.

Cheers,

Jeff

pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #15589: Due to missing wal,restore ends prematurely and opens database for read/write
Next
From: PG Bug reporting form
Date:
Subject: BUG #15590: crosstab_hash unable to work with modified types(CreateTupleDescCopy returning dropped attributes?)