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

From: leif(at)lako(dot)no
To: "Jeff Janes" <jeff(dot)janes(at)gmail(dot)com>, pgsql-bugs(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-12 07:40:07
Message-ID: d8b925764876064175d94447e698ec69@lako.no
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

"Jeff Janes" <jeff(dot)janes(at)gmail(dot)com (mailto:jeff(dot)janes(at)gmail(dot)com?to=%22Jeff%20Janes%22%20<jeff(dot)janes(at)gmail(dot)com>)> skrev 11. januar 2019 kl. 15:03:
On Fri, Jan 11, 2019 at 4:08 AM PG Bug reporting form <noreply(at)postgresql(dot)org (mailto:noreply(at)postgresql(dot)org)> wrote:
PostgreSQL should have paused recovery also on the first scenario. Then I
could have added missing wal and continued with restore.
At the least, I think we should log an explicit WARNING if the WAL stream ends before the specified PIT is reached.
The documentation for recovery.conf states that with recovery_target_time set recovery_target_action defaults to pause.
Even if stop point is not reached, pause should be activated.
After checking the source this might be solved with a small addition in StartupXLOG.c
Someone with more experience with the source code should check this out.
if (reachedStopPoint)
{
if (!reachedConsistency)
ereport(FATAL,
(errmsg("requested recovery stop point is before consistent recovery point")));
/*
* This is the last point where we can restart recovery with a
* new recovery target, if we shutdown and begin again. After
* this, Resource Managers may choose to do permanent
* corrective actions at end of recovery.
*/
switch (recoveryTargetAction)
{
case RECOVERY_TARGET_ACTION_SHUTDOWN:
/*
* exit with special return code to request shutdown
* of postmaster. Log messages issued from
* postmaster.
*/
proc_exit(3);
case RECOVERY_TARGET_ACTION_PAUSE:
SetRecoveryPause(true);
recoveryPausesHere();
/* drop into promote */
case RECOVERY_TARGET_ACTION_PROMOTE:
break;
}
/* Add these lines .... */
} else if (recoveryTarget == RECOVERY_TARGET_TIME)
{
/*
* Stop point not reached but next WAL could not be read
* Some explanation and warning should be logged
*/
switch (recoveryTargetAction)
{
case RECOVERY_TARGET_ACTION_PAUSE:
SetRecoveryPause(true);
recoveryPausesHere();
break;
}
}
/* .... until here */
--

Leif

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Дилян Палаузов 2019-01-13 10:47:50 psql and readline comments
Previous Message leif 2019-01-12 05:59:54 Re: BUG #15589: Due to missing wal, restore ends prematurely and opens database for read/write

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2019-01-12 07:49:22 Re: [HACKERS] PATCH: multivariate histograms and MCV lists
Previous Message leif 2019-01-12 05:59:54 Re: BUG #15589: Due to missing wal, restore ends prematurely and opens database for read/write