public inbox for [email protected]  

help / color / mirror / Atom feed

From: Sami Imseih <[email protected]>
To: Bertrand Drouvot <[email protected]>
To: Nathan Bossart <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: Restart pg_usleep when interrupted
Date: Tue, 20 Aug 2024 14:25:19 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <ZsSSRCkUE41/[email protected]>
References: <ZrpnfTVK-iaIW98I@nathan>
	<[email protected]>
	<[email protected]>
	<ZrqG0tIgP2HbGRm1@nathan>
	<[email protected]>
	<Zrt3ReA-nB7MJn2q@nathan>
	<[email protected]>
	<ZruCZOKzS0LGAGTb@nathan>
	<[email protected]>
	<ZruMe-ppopQX4uP8@nathan>
	<ZsSSRCkUE41/[email protected]>

> 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%40ma...
[3] https://www.postgresql.org/message-id/CA%2BhUKGKpo3fM%3DrnfdxHqt%2BjNGh_zUNcL1ob4hMsb%3DjFfKn9Aag%40...
[4] https://www.postgresql.org/message-id/e3297b5e-0b33-4f45-afcd-4b00ba0b3547%40gmail.com
[5] https://www.postgresql.org/message-id/[email protected]...

view thread (18+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Restart pg_usleep when interrupted
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox