Re: Remove non-fast promotion Re: Should we remove a fallbackpromotion? take 2
От | Fujii Masao |
---|---|
Тема | Re: Remove non-fast promotion Re: Should we remove a fallbackpromotion? take 2 |
Дата | |
Msg-id | 9281e6cf-7387-76ce-cae2-e82ba6501fed@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: Remove non-fast promotion Re: Should we remove a fallbackpromotion? take 2 (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Remove non-fast promotion Re: Should we remove a fallbackpromotion? take 2
|
Список | pgsql-hackers |
On 2020/04/21 14:54, Michael Paquier wrote: > On Tue, Apr 21, 2020 at 02:27:20PM +0900, Fujii Masao wrote: >> On 2020/04/21 10:59, Michael Paquier wrote: >>> With your patch, this code >>> now means that in order to finish recovery you need to send SIGUSR2 to >>> the startup process *and* to create the promote signal file. >> >> Yes, but isn't this the same as the way to trigger fast promotion in HEAD? > > Yep, but my point is that some users who have been relying only on > SIGUSR2 sent to the startup process for a promotion may be surprised > to see that doing the same operation does not trigger a promotion > anymore. Yeah, but that's not documented. So I don't think that we need to keep the backward-compatibility for that. Also in that case, non-fast promotion is triggered. Since my patch tries to remove non-fast promotion, it's intentional to prevent them from doing that. But you think that we should not drop that because there are still some users for that? Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: