Re: PITR potentially broken in 9.2

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: PITR potentially broken in 9.2
Дата
Msg-id 20121205173025.GD27424@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: PITR potentially broken in 9.2  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: PITR potentially broken in 9.2  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
On 2012-12-05 17:24:42 +0000, Simon Riggs wrote:
> On 5 December 2012 17:17, Simon Riggs <simon@2ndquadrant.com> wrote:
>
> > The recovery target and the consistency point are in some ways in
> > conflict. If the recovery target is before the consistency point there
> > is no point in stopping there, whether or not we pause. What we should
> > do is say "recovery target reached, yet recovery not yet consistent,
> > continuing".
> > So ISTM that we should make recoveryStopsHere() return false while we
> > are inconsistent. Problems solved.

I prefer the previous (fixed) behaviour where we error out if we reach a
recovery target before we are consistent:

    /*
     * Complain if we did not roll forward far enough to render the backup
     * dump consistent.  Note: it is indeed okay to look at the local variable
     * minRecoveryPoint here, even though ControlFile->minRecoveryPoint might
     * be further ahead --- ControlFile->minRecoveryPoint cannot have been
     * advanced beyond the WAL we processed.
     */
    if (InRecovery &&
        (XLByteLT(EndOfLog, minRecoveryPoint) ||
         !XLogRecPtrIsInvalid(ControlFile->backupStartPoint)))
    {
        if (reachedStopPoint)
        {
            /* stopped because of stop request */
            ereport(FATAL,
                    (errmsg("requested recovery stop point is before consistent recovery point")));
        }

        /*
         * Ran off end of WAL before reaching end-of-backup WAL record, or
         * minRecoveryPoint. That's usually a bad sign, indicating that you
         * tried to recover from an online backup but never called
         * pg_stop_backup(), or you didn't archive all the WAL up to that
         * point. However, this also happens in crash recovery, if the system
         * crashes while an online backup is in progress. We must not treat
         * that as an error, or the database will refuse to start up.
         */
        if (InArchiveRecovery || ControlFile->backupEndRequired)
        {
            if (ControlFile->backupEndRequired)
                ereport(FATAL,
                        (errmsg("WAL ends before end of online backup"),
                         errhint("All WAL generated while online backup was taken must be available at recovery.")));
            else if (!XLogRecPtrIsInvalid(ControlFile->backupStartPoint))
                ereport(FATAL,
                        (errmsg("WAL ends before end of online backup"),
                         errhint("Online backup started with pg_start_backup() must be ended with pg_stop_backup(), and
allWAL up to that point must be available at recovery."))); 
            else
                ereport(FATAL,
                      (errmsg("WAL ends before consistent recovery point")));
        }
    }

Seems to be good enough to me. Once the pause logic is fixed obviously.


Greetings,

Andres Freund

--
 Andres Freund                       http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: PITR potentially broken in 9.2
Следующее
От: Tom Lane
Дата:
Сообщение: Re: PITR potentially broken in 9.2