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

From: leif(at)lako(dot)no
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Fwd: Re: BUG #15589: Due to missing wal, restore ends prematurely and opens database for read/write
Date: 2019-01-23 06:57:27
Message-ID: 85a0cdd7cefa306a12c390967021500b@lako.no
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

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 have created an suggestion to make a small addition to StartupXLOG.c to solve the issue.

Any suggestions?

--
Leif Gunnar Erlandsen

-------- Videresendt melding -------
Fra: leif(at)lako(dot)no (mailto:leif(at)lako(dot)no)
Til: "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>)>, pgsql-bugs(at)lists(dot)postgresql(dot)org (mailto:pgsql-bugs(at)lists(dot)postgresql(dot)org)
Sendt: 12. januar 2019 kl. 08:40
Emne: Re: BUG #15589: Due to missing wal, restore ends prematurely and opens database for read/write
"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

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrew Gierth 2019-01-23 06:57:36 Re: BUG #15604: NOT IN condition incorrectly returns False
Previous Message PG Bug reporting form 2019-01-23 00:44:15 BUG #15604: NOT IN condition incorrectly returns False

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2019-01-23 08:33:11 Re: pg_dump multi VALUES INSERT
Previous Message David Rowley 2019-01-23 06:50:45 Re: pg_dump multi VALUES INSERT