Re: Wait event that should be reported while waiting for WALarchiving to finish
Вложения
В списке pgsql-hackers по дате отправления:
| От | Michael Paquier |
|---|---|
| Тема | Re: Wait event that should be reported while waiting for WALarchiving to finish |
| Дата | |
| Msg-id | 20200218033949.GD4176@paquier.xyz обсуждение |
| Ответ на | Re: Wait event that should be reported while waiting for WALarchiving to finish (Fujii Masao <masao.fujii@oss.nttdata.com>) |
| Ответы |
Re: Wait event that should be reported while waiting for WALarchiving to finish
|
| Список | pgsql-hackers |
On Mon, Feb 17, 2020 at 10:21:23PM +0900, Fujii Masao wrote: > On 2020/02/17 18:48, Michael Paquier wrote: >> Actually, I have some questions: >> 1) Should a new wait event be added in recoveryPausesHere()? That >> would be IMO useful. > > Yes, it's useful, I think. But it's better to implement that > as a separate patch. No problem for me. >> 2) Perhaps those two points should be replaced with WaitLatch(), where >> we would use the new wait events introduced? > > For what? Maybe it should, but I'm not sure it's worth the trouble. I don't have more to offer than signal handling consistency for both without relying on pg_usleep()'s behavior depending on the platform, and power consumption. For the recovery pause, the second argument may not be worth carrying, but we never had this argument for the archiving wait, did we? For both, on top of it you don't need to worry about concurrent issues with the wait events attached around. -- Michael
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера