Re: BUG #15589: Due to missing wal, restore ends prematurely and opens database for read/write

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: leif(at)lako(dot)no
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15589: Due to missing wal, restore ends prematurely and opens database for read/write
Date: 2019-01-31 12:26:48
Message-ID: 20190131.212648.235621599.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

At Wed, 30 Jan 2019 15:53:51 +0000, leif(at)lako(dot)no wrote in <a3bf3b8910cd5adb8a5fbc8113eac0ab(at)lako(dot)no>
> Hi
> I have reported a bug via PostgreSQL bug report form, but havent got any response so far.
> This might not be a bug, but a feature not implemented yet.
> I suggest to make a small addition to StartupXLOG to solve the issue.

I can understand what you want, but it doesn't seem acceptable
since it introduces inconsistency among target kinds.

> The scenario I want to solve is:
> Need to restore backup to another server.
> Restores pgbasebackup files
> Restores som wal-files
> Extract pgbasebackup files
> creates recover.conf with pit
> Starts postgresql
> recover ends before pit due to missing wal-files
> database opens read/write
>
> I think database should have paused recovery then I could restore
> additional wal-files and restart postgresql to continue with recover.

I don't think no one expected that server follows
recovery_target_action without setting a target, so we can change
the behavior when any kind of target is specified. So I propose
to follow recovery_target_action even if not rached the target
when any recovery target isspecified.

With the attached PoC (for master), recovery stops as follows:

LOG: consistent recovery state reached at 0/2F000000
LOG: database system is ready to accept read only connections
rc_work/00000001000000000000002F’: No such file or directory
WARNING: not reached specfied recovery target, take specified action anyway
DETAIL: This means a wrong target or missing of expected WAL files.
LOG: recovery has paused
HINT: Execute pg_wal_replay_resume() to continue.

If no target is specifed, it promtes immediately ignoring r_t_action.

If this is acceptable I'll post complete version (including
documentation). I don't think this back-patcheable.

> With large databases and a lot of wal-files it is time consuming to repeat parts of the process.

I understand your concern.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
stop_recovery_before_target.patch text/x-patch 1.1 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David Conlin 2019-01-31 14:29:40 Re: BUG #15614: Query plan: buffer stats from workers in child operations discarded.
Previous Message Дилян Палаузов 2019-01-31 11:46:49 Re: psql and readline comments

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2019-01-31 12:33:25 Re: WIP: Avoid creation of the free space map for small tables
Previous Message Etsuro Fujita 2019-01-31 11:53:15 Re: [HACKERS] advanced partition matching algorithm for partition-wise join