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?
|
Список | 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 по дате отправления: