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

At Wed, 30 Jan 2019 15:53:51 +0000, leif@lako.no wrote in <a3bf3b8910cd5adb8a5fbc8113eac0ab@lako.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
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 2ab7d804f0..081bdd86ec 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7246,12 +7246,25 @@ StartupXLOG(void)
              * end of main redo apply loop
              */
 
-            if (reachedStopPoint)
+            /*
+             * If recovery target is specified, specified action is expected
+             * to be taken regardless whether the target is reached or not .
+             */
+            if (recoveryTarget != RECOVERY_TARGET_UNSET)
             {
+                /*
+                 * At this point we don't consider the case where we are
+                 * before consistent point even if not reached stop point.
+                 */
                 if (!reachedConsistency)
                     ereport(FATAL,
                             (errmsg("requested recovery stop point is before consistent recovery point")));
 
+                if (!reachedStopPoint)
+                    ereport(WARNING,
+                            (errmsg ("not yet reached specfied recovery target, take specified action anyway"),
+                             errdetail("This means a wrong target or missing WAL files.")));
+
                 /*
                  * This is the last point where we can restart recovery with a
                  * new recovery target, if we shutdown and begin again. After