From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Melanie Plageman <melanieplageman(at)gmail(dot)com> |
Subject: | Re: Streaming I/O, vectored I/O (WIP) |
Date: | 2023-12-11 09:37:13 |
Message-ID: | CA+hUKGKEJvumpked4gbToKi+70dsZDVcaoEMBWcX5nwLqth6Rg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Dec 11, 2023 at 10:28 PM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> 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 guess I just wanted to preserve pg_pwritev_with_retry()'s existing
prototype, primarily because it matches standard pwritev()/writev().
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2023-12-11 09:44:46 | Re: Adding facility for injection points (or probe points?) for more advanced tests |
Previous Message | shveta malik | 2023-12-11 09:30:50 | Re: Synchronizing slots from primary to standby |