Message-ID: <2b5ac681-11d5-470d-af40-89ead9a868aa@gmail.com>
Date: Mon, 12 Aug 2024 17:35:08 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Restart pg_usleep when interrupted
To: Nathan Bossart <nathandbossart@gmail.com>,
 Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
 Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>,
 "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
References: <ZrZtdpTN7nLI4L8h@ip-10-97-1-34.eu-west-3.compute.internal>
 <9D64CD7C-CA24-4FF4-9421-3A1A63F87DAC@gmail.com>
 <526E6A51-FE30-47C4-85C8-F2D18877607F@gmail.com>
 <ZrmcoWn1q2hQv0QU@ip-10-97-1-34.eu-west-3.compute.internal>
 <AED4B8D0-3ED1-463C-BA9F-BFF4B511315E@gmail.com>
 <BB742B52-D481-4D5A-926A-4ED4A6ADA98B@gmail.com>
 <ZrowomFX5yMV9zUm@ip-10-97-1-34.eu-west-3.compute.internal>
 <ZrpnfTVK-iaIW98I@nathan> <e3297b5e-0b33-4f45-afcd-4b00ba0b3547@gmail.com>
 <cb18c6a7-4394-4488-ad71-0b9826c8899c@iki.fi> <ZrqG0tIgP2HbGRm1@nathan>
Content-Language: en-US
From: "Imseih (AWS), Sami" <samimseih@gmail.com>
In-Reply-To: <ZrqG0tIgP2HbGRm1@nathan>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/2b5ac681-11d5-470d-af40-89ead9a868aa%40gmail.com>
Precedence: bulk


> Skimming the last few messages of that thread [0], it looks like Bertrand
> is exploring ways to avoid so many interrupts.  I guess the unavoidable
> question is whether this work is still worthwhile given that improvement.
The way the instrumentation in [0] dealt with interrupts was too complex,
which is why it seemed better to handle the restart the remainder of the
sleep in the sleep function
>> On the patch itself: Making the sleeps in vacuum uninterruptible means that
>> vacuum will be more slow to respond to interrupts. If you SIGTERM a vacuum
>> process, or hit CTRL-C, you *would* want to exit the sleep ASAP.
> Since the delay will typically be pretty small (2 milliseconds by default
> for autovacuum), I'm assuming this won't ordinarily be noticeable.  But I
> do think it is an important consideration.
>
At most, the sleep will be 100ms for vacuum.

>
> Tom raised that concern earlier in this thread 
> (https://www.postgresql.org/message-id/2100439.1719610468%40sss.pgh.pa.us), 
> but it seems the discussion wandered off to the details of how to do 
> the sleep, and left that unaddressed.
>
Doing something like pg_sleep, using WaitLatch [1], was explored. 
However this
does not support microsecond sleeps which was allowed in 720de00af49
Thomas shared WaitLatchUs [2], which supports higher precision sleeps, but
it requires epoll_pwait(2) on the system, thus it's not very portable.
Using nanosleep with remain time and checking for drift was the most 
portable
approach.

Regards,

Sami

[0] https://commitfest.postgresql.org/49/5027/
[1] https://www.postgresql.org/message-id/67072E39-3B4E-4240-8373-AC45E23721E7%40gmail.com
[2] https://www.postgresql.org/message-id/CA+hUKGKVbJE59JkwnUj5XMY+-rzcTFciV9vVC7i=LUfWPds8Xw@mail.gmail.com