> From this discussion, there is desire for a sleep function that: > 1/ Sleeps for the full duration of the requested time > 2/ Continues to handle important interrupts during the sleep > > While something like CF 5118 will take care of point #1,
> I'm not sure, even with CF entry 5118, nanosleep() could be interrupted. But I > agree that the leader won't be interrupted by PqMsg_Progress anymore. Correct. > 1. we should still implement the "1 Hz" stuff as 1.1/ it could be useful if CF > 5118 gets committed and we move to WaitLatchUs() and 2.2/ it won't break > anything > if CF gets committed and we don't move to WaitLatchUs(). For 1.1 it would > still > prevent the leader to be waked up too frequently by the parallel workers. Yes, regardless of any changes that may occur in the future that change the behaior of pg_usleep, preventing a leader from being woken up too frequently is good to have. The "1 Hz" work is still good to have. > 2. still discuss the "need" and get a consensus regarding a sleep that could > ensure the wait duration (in some cases and depending of the reason why the > process is waked up). Unless there is objection, I will withdraw the CF [1] entry for this patch next week. This discussion however should be one of the points that CF 5118 must deal with. That is, 5118 will change the behavior of pg_usleep when dealing with interrupts previously signaled by SIGUSR1. [1] https://commitfest.postgresql.org/49/5161/ Regards, Sami
