Date: Mon, 5 Oct 2020 11:25:51 -0300
From: =?iso-8859-1?Q?=C1lvaro?= Herrera <alvherre@alvh.no-ip.org>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Daniel Gustafsson <daniel@yesql.se>,
	Justin Pryzby <pryzby@telsasoft.com>,
	Robert Haas <robertmhaas@gmail.com>,
	Magnus Hagander <magnus@hagander.net>,
	Michael Paquier <michael@paquier.xyz>,
	Andres Freund <andres@anarazel.de>,
	Tomas Vondra <tomas.vondra@2ndquadrant.com>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: Online checksums patch - once again
Message-ID: <20201005142551.GA9146@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b832a496-f0aa-c7e4-cca4-6bd0af4d4a90@iki.fi>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On 2020-Oct-05, Heikki Linnakangas wrote:

> The code in sendFile() in basebackup.c seems suspicious in that regard. It
> calls DataChecksumsNeedVerify() once before starting to read the file. Isn't
> it possible for the checksums flag to change while it's reading the file and
> sending it to the client? I hope there are CHECK_FOR_INTERRUPTS() calls
> buried somewhere in the loop, because it could take minutes to send the
> whole file.
> 
> I would feel better if the state transition of the "checksums" flag could
> only happen in a few safe places, or there were some other safeguards for
> this. I think that's what Andres was trying to say earlier in the thread on
> ProcSignalBarriers. I'm not sure what the interface to that should be. It
> could be something like HOLD/RESUME_INTERRUPTS(), where normally all
> procsignals are handled on CHECK_FOR_INTERRUPTS(), but you could "hold off"
> some if needed. Or something else. Or maybe we can just use
> HOLD/RESUME_INTERRUPTS() for this. It's more coarse-grained than necessary,
> but probably doesn't matter in practice.

I hope you're not suggesting that interrupts would be held for the whole
transmission of a file, which you say could take minutes.  If we do have
an interrupt holdoff, then it has to be pretty short; users (and
systemd) despair if service shutdown is delayed more than a few seconds.