Message-ID: <8f5aca0a-4d12-46e8-8ce4-d196acfa8baf@iki.fi>
Date: Mon, 11 Dec 2023 11:27:58 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Streaming I/O, vectored I/O (WIP)
Content-Language: en-US
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Andres Freund <andres@anarazel.de>,
 pgsql-hackers <pgsql-hackers@postgresql.org>,
 Melanie Plageman <melanieplageman@gmail.com>
References: 
 <CA+hUKGJkOiOCa+mag4BF+zHo7qo=o9CFheB8=g6uT5TUm2gkvA@mail.gmail.com>
 <b336fbe8-1ad0-c289-5ed8-bbb74513e5bb@iki.fi>
 <CA+hUKGKOc4=TTNv_r4F03QafvK7qo7itN+OwUdMX5UMjYiqybA@mail.gmail.com>
 <1c6f0c38-9181-4869-983f-3d6ef17dea3c@iki.fi>
 <CA+hUKGJywvC5J+rcLs3+whK8YPBnKXVLn5o0JFJbNeb4CEdSFA@mail.gmail.com>
 <f748992c-26f1-4389-9349-06a0ab75046c@iki.fi>
 <CA+hUKG+ZLXp1jk+ML11GedOUKw9mEzAie3nmY9041CygNpd=9w@mail.gmail.com>
 <20231208182554.swereaxcgvq72ts6@awork3.anarazel.de>
 <CA+hUKGJLW3pwf7yWWCkoLD+kGb_J3B+Q-oa9ufq82_HAsW0QxA@mail.gmail.com>
 <4533e76e-9519-4715-acd0-d4fa552619b0@iki.fi>
 <CA+hUKGK1GwoxONGftaP8M0git=Mo15oKytasY+ChV-2hF+726Q@mail.gmail.com>
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: 
 <CA+hUKGK1GwoxONGftaP8M0git=Mo15oKytasY+ChV-2hF+726Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/8f5aca0a-4d12-46e8-8ce4-d196acfa8baf%40iki.fi>
Precedence: bulk

On 11/12/2023 11:12, Thomas Munro wrote:
> 1.  I eventually figured out how to generalise
> compute_remaining_iovec() (as I now call it) so that the existing
> pg_pwritev_with_retry() in file_utils.c could also use it, so that's
> now done in a patch of its own.

In compute_remaining_iovec():
> 'source' and 'destination' may point to the same array, in which
> case it is adjusted in-place; otherwise 'destination' must have enough
> space for 'iovcnt' elements.
Is there any use case for not adjusting it in place? 
pg_pwritev_with_retry() takes a const iovec array, but maybe just remove 
the 'const' and document that it scribbles on it?

> I'm planning to commit these fairly soon.

+1

-- 
Heikki Linnakangas
Neon (https://neon.tech)