User-Agent: Microsoft-MacOutlook/16.86.24062313
Date: Tue, 20 Aug 2024 14:25:19 -0500
Subject: Re: Restart pg_usleep when interrupted
From: Sami Imseih <samimseih@gmail.com>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
	Nathan Bossart <nathandbossart@gmail.com>
CC: Heikki Linnakangas <hlinnaka@iki.fi>,
	Tom Lane <tgl@sss.pgh.pa.us>,
	Robert Haas <robertmhaas@gmail.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Message-ID: <40F4611D-C92D-4569-8C4A-87A7DAAC4A09@gmail.com>
Thread-Topic: Restart pg_usleep when interrupted
References: <ZrpnfTVK-iaIW98I@nathan>
 <e3297b5e-0b33-4f45-afcd-4b00ba0b3547@gmail.com>
 <cb18c6a7-4394-4488-ad71-0b9826c8899c@iki.fi>
 <ZrqG0tIgP2HbGRm1@nathan>
 <2b5ac681-11d5-470d-af40-89ead9a868aa@gmail.com>
 <Zrt3ReA-nB7MJn2q@nathan>
 <90ec1618-58db-46b3-8c9b-13616ac839a7@gmail.com>
 <ZruCZOKzS0LGAGTb@nathan>
 <ac329991-7cfa-4006-b155-97ba19c5705d@gmail.com>
 <ZruMe-ppopQX4uP8@nathan>
 <ZsSSRCkUE41/rTZM@ip-10-97-1-34.eu-west-3.compute.internal>
In-Reply-To: <ZsSSRCkUE41/rTZM@ip-10-97-1-34.eu-west-3.compute.internal>
Mime-version: 1.0
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/40F4611D-C92D-4569-8C4A-87A7DAAC4A09%40gmail.com>
Precedence: bulk

> 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