Date: Tue, 13 Aug 2024 16:30:46 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: "Imseih (AWS), Sami" <samimseih@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>,
	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>
Subject: Re: Restart pg_usleep when interrupted
Message-ID: <ZrvQhkrqFrLbu4kl@nathan>
References: <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>
 <b612b9cd-b59e-43d1-bb8a-e100c5ab9849@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b612b9cd-b59e-43d1-bb8a-e100c5ab9849@gmail.com>
Archived-At: <https://www.postgresql.org/message-id/ZrvQhkrqFrLbu4kl%40nathan>
Precedence: bulk

On Tue, Aug 13, 2024 at 01:12:30PM -0500, Imseih (AWS), Sami wrote:
>> None of this seems intractable to me.  1 Hz seems like an entirely
>> reasonable place to start, and it is very easy to change (or to even make
>> configurable).  pg_stat_progress_vacuum might show slightly old values in
>> this column, but that should be easy enough to explain in the docs if we
>> are really concerned about it.  If other callers want to do something
>> similar, maybe we should add a more generic implementation in
>> backend_progress.c.
>> 
> I don't know if I agree. Making vacuum sleep more robust to handle
> interrupts seems like a cleaner general solution than to add
> even more code to handle this case or have to explain the behavior of
> cost delay instrumentation in docs.

Another concern is the huge number of PqMsg_Progress messages sent by
parallel workers with that approach.  In Bertrand's tests, he was seeing
nearly 350K interrupts for a ~19 minute vacuum (~300 interrupts per
second).  That seems a bit extreme to me.  I don't see how anyone could
possibly need stats about vacuum delays with that level of accuracy.

-- 
nathan