Re: [HACKERS] Fast promotion not used when doing a recovery_targetPITR restore?

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [HACKERS] Fast promotion not used when doing a recovery_targetPITR restore?
Дата
Msg-id 20170622173459.skhepqxq3glp3pwz@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: [HACKERS] Fast promotion not used when doing a recovery_targetPITR restore?  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: [HACKERS] Fast promotion not used when doing a recovery_targetPITR restore?  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
On 2017-06-22 14:04:42 +0900, Michael Paquier wrote:
> On Thu, Jun 22, 2017 at 3:04 AM, Andres Freund <andres@anarazel.de> wrote:
> > When doing a PITR style recovery, with recovery target set, we're
> > currently not doing a fast promotion, in contrast to the handling when
> > doing a pg_ctl or trigger file based promotion. That can prolong making
> > the server available for writes.
> >
> > I can't really see a reason for this?
> 
> Yes, you are right. I see no reason either why this cannot be done.
> Why not just switching fast_promote to true in when using
> RECOVERY_TARGET_ACTION_PROMOTE? That's a bug, not a critical one
> though.

I don't think it's really a bug - just a missed optimization.  I'd
personally not be in favor of backpatching this - it'll have some chance
of screwing things up, even if I hope that chance is fairly small.

As a wider discussion, I wonder if we should keep non-fast promotion for
anything but actual crash recovery?  And even there it might actually be
a pretty good idea to not force a full checkpoint - getting up fast
after a crash is kinda important..

Andres Freund



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] possible self-deadlock window after bad ProcessStartupPacket
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Stale comments in vacuumlazy.c