From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: Streaming I/O, vectored I/O (WIP) |
Date: | 2024-03-28 11:16:47 |
Message-ID: | CA+hUKG+5UofvseJWv6YqKmuc_=rguc7VqKcNEG1eawKh3MzHXQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Mar 29, 2024 at 12:06 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> Small bug fix: the condition in the final test at the end of
> read_stream_look_ahead() wasn't quite right. In general when looking
> ahead, we don't need to start a read just because the pending read
> would bring us up to stream->distance if submitted now (we'd prefer to
> build it all the way up to size io_combine_limit if we can), but if
> that condition is met AND we have nothing pinned yet, then there is no
> chance for the read to grow bigger by a pinned buffer being consumed.
> Fixed, comment updated.
Oops, I sent the wrong/unfixed version. This version has the fix
described above.
Attachment | Content-Type | Size |
---|---|---|
v13-0001-Provide-vectored-variant-of-ReadBuffer.patch | application/octet-stream | 38.8 KB |
v13-0002-Provide-API-for-streaming-relation-data.patch | application/octet-stream | 33.2 KB |
v13-0003-Use-streaming-I-O-in-pg_prewarm.patch | application/octet-stream | 2.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Ranier Vilela | 2024-03-28 11:30:23 | Re: Fix some resources leaks (src/bin/pg_basebackup/pg_createsubscriber.c) |
Previous Message | Matthias van de Meent | 2024-03-28 11:15:27 | Re: Experiments with Postgres and SSL |