Re: Wait event that should be reported while waiting for WALarchiving to finish
От | Fujii Masao |
---|---|
Тема | Re: Wait event that should be reported while waiting for WALarchiving to finish |
Дата | |
Msg-id | d9d85efa-f62e-400e-2edf-9e1b8c0df651@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: Wait event that should be reported while waiting for WALarchiving to finish (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Wait event that should be reported while waiting for WALarchiving to finish
|
Список | pgsql-hackers |
On 2020/02/17 18:48, Michael Paquier wrote: > On Mon, Feb 17, 2020 at 04:30:00PM +0900, Fujii Masao wrote: >> On 2020/02/14 23:43, Robert Haas wrote: >>> On Thu, Feb 13, 2020 at 10:47 PM Fujii Masao >>> <masao.fujii@oss.nttdata.com> wrote: >>>> Fixed. Thanks for the review! >>> >>> I think it would be safer to just report the wait event during >>> pg_usleep(1000000L) rather than putting those calls around the whole >>> loop. It does not seem impossible that ereport() or >>> CHECK_FOR_INTERRUPTS() could do something that reports a wait event >>> internally. > > CHECK_FOR_INTERRUPTS() would reset the event wait state. Hm.. You > may be right about the WARNING and it would be better to not rely on > that. Do you remember the states which may be triggered? > >> OK, so I attached the updated version of the patch. >> Thanks for the review! > > 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. > 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. Regards, -- Fujii Masao NTT DATA CORPORATION Advanced Platform Technology Group Research and Development Headquarters
В списке pgsql-hackers по дате отправления: