> As it looks like we have a consensus that reducing the number of interrupts also
> makes sense, I just provided a rebase version of the 1 Hz version (see [0], that
> also makes clear in the doc that the new field might show slightly old values).
That makes sense. However, I suspect the "1 Hz" work code will no longer
be needed if CF entry 5118 [1] mentioned by Thomas [2] a few days back
goes through. Maybe this extra work can be removed if [1] goes through.
What do you think?
With regards to CF 5118 and what it means to the current discussion, below
are my thoughts.
I tested with both CF 5118 [1] and the cost-delay tracking patch. With that in place,
pg_usleep is able to sleep the full requested, as mentioned by Thomas [3]. This is
because certain interrupts like Parallel Message and others are not signaled
by SIGUSR1 any longer, but with latches.
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, it will not deal
with #2. Also, the v11 [4] patch does not do #2 either. So I think
in the sleep loop, we need a C_F_I call. The same type of loop can
also be used to call WaitForSingleObject.
If CF 5118 gets committed, will still need similar loop that calls C_F_I,
but the function will need to call WaitLatchUs [5].
Thoughts?
--
Sami
[1] https://commitfest.postgresql.org/49/5118/
[2] https://www.postgresql.org/message-id/CA%2BhUKG%2Bf-nEc_SowDLW1JMUa6Of5sCK-JZ%3Dv-KhL1xgXk83fiw%40mail.gmail.com
[3] https://www.postgresql.org/message-id/CA%2BhUKGKpo3fM%3DrnfdxHqt%2BjNGh_zUNcL1ob4hMsb%3DjFfKn9Aag%40mail.gmail.com
[4] https://www.postgresql.org/message-id/e3297b5e-0b33-4f45-afcd-4b00ba0b3547%40gmail.com
[5] https://www.postgresql.org/message-id/CA+hUKGKVbJE59JkwnUj5XMY+-rzcTFciV9vVC7i=LUfWPds8Xw@mail.gmail.com
