Thread: pgsql: aio: Add core asynchronous I/O infrastructure
aio: Add core asynchronous I/O infrastructure The main motivations to use AIO in PostgreSQL are: a) Reduce the time spent waiting for IO by issuing IO sufficiently early. In a few places we have approximated this using posix_fadvise() based prefetching, but that is fairly limited (no completion feedback, double the syscalls, only works with buffered IO, only works on some OSs). b) Allow to use Direct-I/O (DIO). DIO can offload most of the work for IO to hardware and thus increase throughput / decrease CPU utilization, as well as reduce latency. While we have gained the ability to configure DIO in d4e71df6, it is not yet usable for real world workloads, as every IO is executed synchronously. For portability, the new AIO infrastructure allows to implement AIO using different methods. The choice of the AIO method is controlled by the new io_method GUC. As of this commit, the only implemented method is "sync", i.e. AIO is not actually executed asynchronously. The "sync" method exists to allow to bypass most of the new code initially. Subsequent commits will introduce additional IO methods, including a cross-platform method implemented using worker processes and a linux specific method using io_uring. To allow different parts of postgres to use AIO, the core AIO infrastructure does not need to know what kind of files it is operating on. The necessary behavioral differences for different files are abstracted as "AIO Targets". One example target would be smgr. For boring portability reasons, all targets currently need to be added to an array in aio_target.c. This commit does not implement any AIO targets, just the infrastructure for them. The smgr target will be added in a later commit. Completion (and other events) of IOs for one type of file (i.e. one AIO target) need to be reacted to differently, based on the IO operation and the callsite. This is made possible by callbacks that can be registered on IOs. E.g. an smgr read into a local buffer does not need to update the corresponding BufferDesc (as there is none), but a read into shared buffers does. This commit does not contain any callbacks, they will be added in subsequent commits. For now the AIO infrastructure only understands READV and WRITEV operations, but it is expected that more operations will be added. E.g. fsync/fdatasync, flush_range and network operations like send/recv. As of this commit, nothing uses the AIO infrastructure. Later commits will add an smgr target, md.c and bufmgr.c callbacks and then finally use AIO for read_stream.c IO, which, in one fell swoop, will convert all read stream users to AIO. The goal is to use AIO in many more places. There are patches to use AIO for checkpointer and bgwriter that are reasonably close to being ready. There also are prototypes to use it for WAL, relation extension, backend writes and many more. Those prototypes were important to ensure the design of the AIO subsystem is not too limiting (e.g. WAL writes need to happen in critical sections, which influenced a lot of the design). A future commit will add an AIO README explaining the AIO architecture and how to use the AIO subsystem. The README is added later, as it references details only added in later commits. Many many more people than the folks named below have contributed with feedback, work on semi-independent patches etc. E.g. various folks have contributed patches to use the read stream infrastructure (added by Thomas in b5a9b18cd0b) in more places. Similarly, a *lot* of folks have contributed to the CI infrastructure, which I had started to work on to make adding AIO feasible. Some of the work by contributors has gone into the "v1" prototype of AIO, which heavily influenced the current design of the AIO subsystem. None of the code from that directly survives, but without the prototype, the current version of the AIO infrastructure would not exist. Similarly, the reviewers below have not necessarily looked at the current design or the whole infrastructure, but have provided very valuable input. I am to blame for problems, not they. Author: Andres Freund <andres@anarazel.de> Co-authored-by: Thomas Munro <thomas.munro@gmail.com> Co-authored-by: Nazir Bilal Yavuz <byavuz81@gmail.com> Co-authored-by: Melanie Plageman <melanieplageman@gmail.com> Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Reviewed-by: Noah Misch <noah@leadboat.com> Reviewed-by: Jakub Wartak <jakub.wartak@enterprisedb.com> Reviewed-by: Melanie Plageman <melanieplageman@gmail.com> Reviewed-by: Robert Haas <robertmhaas@gmail.com> Reviewed-by: Dmitry Dolgov <9erthalion6@gmail.com> Reviewed-by: Antonin Houska <ah@cybertec.at> Discussion: https://postgr.es/m/uvrtrknj4kdytuboidbhwclo4gxhswwcpgadptsjvjqcluzmah%40brqs62irg4dt Discussion: https://postgr.es/m/20210223100344.llw5an2aklengrmn@alap3.anarazel.de Discussion: https://postgr.es/m/stj36ea6yyhoxtqkhpieia2z4krnam7qyetc57rfezgk4zgapf@gcnactj4z56m Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/da7226993fd4b73d8b40abb7167d124eada97f2e Modified Files -------------- src/backend/storage/aio/Makefile | 4 + src/backend/storage/aio/aio.c | 1130 +++++++++++++++++++++++ src/backend/storage/aio/aio_callback.c | 308 ++++++ src/backend/storage/aio/aio_init.c | 198 ++++ src/backend/storage/aio/aio_io.c | 184 ++++ src/backend/storage/aio/aio_target.c | 114 +++ src/backend/storage/aio/meson.build | 4 + src/backend/storage/aio/method_sync.c | 47 + src/backend/utils/activity/wait_event_names.txt | 1 + src/include/storage/aio.h | 311 +++++++ src/include/storage/aio_internal.h | 395 ++++++++ src/include/storage/aio_types.h | 117 +++ src/tools/pgindent/typedefs.list | 21 + 13 files changed, 2834 insertions(+)
Andres Freund <andres@anarazel.de> writes:
> aio: Add core asynchronous I/O infrastructure
Some of the buildfarm is mildly unhappy with this.
So far I see
ayu | 2025-03-18 13:08:04 | aio_callback.c:83:12: warning: comparison of constant 1 with expression of type
'PgAioHandleCallbackID'(aka 'enum PgAioHandleCallbackID') is always false
[-Wtautological-constant-out-of-range-compare]
ayu | 2025-03-18 13:08:04 | aio_callback.c:190:56: warning: comparison of constant 1 with expression of type
'PgAioTargetID'(aka 'enum PgAioTargetID') is always true [-Wtautological-constant-out-of-range-compare]
ayu | 2025-03-18 13:08:04 | aio_callback.c:220:56: warning: comparison of constant 1 with expression of type
'PgAioTargetID'(aka 'enum PgAioTargetID') is always true [-Wtautological-constant-out-of-range-compare]
ayu | 2025-03-18 13:08:04 | aio_callback.c:274:56: warning: comparison of constant 1 with expression of type
'PgAioTargetID'(aka 'enum PgAioTargetID') is always true [-Wtautological-constant-out-of-range-compare]
ayu | 2025-03-18 13:08:04 | aio_target.c:50:41: warning: comparison of constant 1 with expression of type
'PgAioTargetID'(aka 'enum PgAioTargetID') is always true [-Wtautological-constant-out-of-range-compare]
ayu | 2025-03-18 13:08:04 | aio_target.c:110:41: warning: comparison of constant 1 with expression of type
'PgAioTargetID'(aka 'enum PgAioTargetID') is always true [-Wtautological-constant-out-of-range-compare]
demoiselle | 2025-03-18 03:43:46 | aio_callback.c:83:12: warning: comparison of constant 1 with expression of type
'PgAioHandleCallbackID'(aka 'enum PgAioHandleCallbackID') is always false
[-Wtautological-constant-out-of-range-compare]
demoiselle | 2025-03-18 03:43:46 | aio_callback.c:190:56: warning: comparison of constant 1 with expression of type
'PgAioTargetID'(aka 'enum PgAioTargetID') is always true [-Wtautological-constant-out-of-range-compare]
demoiselle | 2025-03-18 03:43:46 | aio_callback.c:220:56: warning: comparison of constant 1 with expression of type
'PgAioTargetID'(aka 'enum PgAioTargetID') is always true [-Wtautological-constant-out-of-range-compare]
demoiselle | 2025-03-18 03:43:46 | aio_callback.c:274:56: warning: comparison of constant 1 with expression of type
'PgAioTargetID'(aka 'enum PgAioTargetID') is always true [-Wtautological-constant-out-of-range-compare]
demoiselle | 2025-03-18 03:43:46 | aio_target.c:50:41: warning: comparison of constant 1 with expression of type
'PgAioTargetID'(aka 'enum PgAioTargetID') is always true [-Wtautological-constant-out-of-range-compare]
demoiselle | 2025-03-18 03:43:46 | aio_target.c:110:41: warning: comparison of constant 1 with expression of type
'PgAioTargetID'(aka 'enum PgAioTargetID') is always true [-Wtautological-constant-out-of-range-compare]
I don't have that compiler handy to check, but maybe changes like
- if (cb_id >= lengthof(aio_handle_cbs))
+ if ((size_t) cb_id >= lengthof(aio_handle_cbs))
would silence these? Or you could just drop all those tests
and have faith in the type-safety of the enums.
regards, tom lane
Hi, On 2025-03-18 11:03:36 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > aio: Add core asynchronous I/O infrastructure > > Some of the buildfarm is mildly unhappy with this. > So far I see > > ayu | 2025-03-18 13:08:04 | aio_callback.c:83:12: warning: comparison of constant 1 with expression of type'PgAioHandleCallbackID' (aka 'enum PgAioHandleCallbackID') is always false [-Wtautological-constant-out-of-range-compare] > ayu | 2025-03-18 13:08:04 | aio_callback.c:190:56: warning: comparison of constant 1 with expression of type'PgAioTargetID' (aka 'enum PgAioTargetID') is always true [-Wtautological-constant-out-of-range-compare] > ayu | 2025-03-18 13:08:04 | aio_callback.c:220:56: warning: comparison of constant 1 with expression of type'PgAioTargetID' (aka 'enum PgAioTargetID') is always true [-Wtautological-constant-out-of-range-compare] > ayu | 2025-03-18 13:08:04 | aio_callback.c:274:56: warning: comparison of constant 1 with expression of type'PgAioTargetID' (aka 'enum PgAioTargetID') is always true [-Wtautological-constant-out-of-range-compare] > ayu | 2025-03-18 13:08:04 | aio_target.c:50:41: warning: comparison of constant 1 with expression of type 'PgAioTargetID'(aka 'enum PgAioTargetID') is always true [-Wtautological-constant-out-of-range-compare] > ayu | 2025-03-18 13:08:04 | aio_target.c:110:41: warning: comparison of constant 1 with expression of type 'PgAioTargetID'(aka 'enum PgAioTargetID') is always true [-Wtautological-constant-out-of-range-compare] > demoiselle | 2025-03-18 03:43:46 | aio_callback.c:83:12: warning: comparison of constant 1 with expression of type'PgAioHandleCallbackID' (aka 'enum PgAioHandleCallbackID') is always false [-Wtautological-constant-out-of-range-compare] > demoiselle | 2025-03-18 03:43:46 | aio_callback.c:190:56: warning: comparison of constant 1 with expression of type'PgAioTargetID' (aka 'enum PgAioTargetID') is always true [-Wtautological-constant-out-of-range-compare] > demoiselle | 2025-03-18 03:43:46 | aio_callback.c:220:56: warning: comparison of constant 1 with expression of type'PgAioTargetID' (aka 'enum PgAioTargetID') is always true [-Wtautological-constant-out-of-range-compare] > demoiselle | 2025-03-18 03:43:46 | aio_callback.c:274:56: warning: comparison of constant 1 with expression of type'PgAioTargetID' (aka 'enum PgAioTargetID') is always true [-Wtautological-constant-out-of-range-compare] > demoiselle | 2025-03-18 03:43:46 | aio_target.c:50:41: warning: comparison of constant 1 with expression of type 'PgAioTargetID'(aka 'enum PgAioTargetID') is always true [-Wtautological-constant-out-of-range-compare] > demoiselle | 2025-03-18 03:43:46 | aio_target.c:110:41: warning: comparison of constant 1 with expression of type 'PgAioTargetID'(aka 'enum PgAioTargetID') is always true [-Wtautological-constant-out-of-range-compare] Thanks for noticing that. > I don't have that compiler handy to check, but maybe changes like > > - if (cb_id >= lengthof(aio_handle_cbs)) > + if ((size_t) cb_id >= lengthof(aio_handle_cbs)) > > would silence these? I wonder if we should instead either ask those buildfarm animals to be disabled or have the warning manually disabled. I don't think it's a good investment on our part to work towards warning cleanliness on clang 4 and 5, on distros from 2017 and and 2018 respectively. > Or you could just drop all those tests and have faith in the type-safety of > the enums. The issue isn't really the type-safety of the enums (not that I would have a lot of trust in that), it's whether the relevant callback/target actually have been added to the the callback/target arrays. Greetings, Andres Freund
Andres Freund <andres@anarazel.de> writes:
> I wonder if we should instead either ask those buildfarm animals to be
> disabled or have the warning manually disabled. I don't think it's a good
> investment on our part to work towards warning cleanliness on clang 4 and 5,
> on distros from 2017 and and 2018 respectively.
Well, if we don't want to fix it I can just adjust my warning-scraping
script to ignore these. Let's wait a bit and see if any newer
compilers warn similarly before deciding.
regards, tom lane
Hi,
On 2025-03-18 11:26:15 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > I wonder if we should instead either ask those buildfarm animals to be
> > disabled or have the warning manually disabled. I don't think it's a good
> > investment on our part to work towards warning cleanliness on clang 4 and 5,
> > on distros from 2017 and and 2018 respectively.
>
> Well, if we don't want to fix it I can just adjust my warning-scraping
> script to ignore these. Let's wait a bit and see if any newer
> compilers warn similarly before deciding.
FWIW, adding a few casts does silence the warnings, at least on clang-3.9,
which I had around.
But there also are other warnings on that compiler, mainly stuff like:
../../home/andres/src/postgresql/src/interfaces/libpq/fe-auth-oauth-curl.c:1437:28: warning: suggest braces around
initializationof subobject [-Wmissing-braces]
struct itimerspec spec = {0};
I lean towards not fixing this stuff, but if you would like me to, I can.
Greetings,
Andres Freund
Andres Freund <andres@anarazel.de> writes:
> On 2025-03-18 11:26:15 -0400, Tom Lane wrote:
>> Well, if we don't want to fix it I can just adjust my warning-scraping
>> script to ignore these. Let's wait a bit and see if any newer
>> compilers warn similarly before deciding.
> FWIW, adding a few casts does silence the warnings, at least on clang-3.9,
> which I had around.
As of now, the only BF members showing these warnings are ayu (clang
version 4.0.1-10~deb9u2), batfish (clang version 5.0.0-3~16.04.1),
and demoiselle (clang version 5.0.1). None of those seem like
versions that anyone would use for code development anymore (clang 6.0
was released in March 2018), so I'm not feeling like these warnings
are important to silence. Let's just ignore them.
> But there also are other warnings on that compiler, mainly stuff like:
> ../../home/andres/src/postgresql/src/interfaces/libpq/fe-auth-oauth-curl.c:1437:28: warning: suggest braces around
initializationof subobject [-Wmissing-braces]
> struct itimerspec spec = {0};
And even more so that, if it's so old it's not even in the buildfarm
anymore. I do care about -Wmissing-braces on a version developers
might use, but ...
regards, tom lane
Hi Andres, > aio: Add core asynchronous I/O infrastructure > > [...] I noticed that aio.c references README.md: ``` * aio.c * AIO - Core Logic * * For documentation about how AIO works on a higher level, including a * schematic example, see README.md. ``` However the file seems to be missing in this commit or in the following ones. Any chance it was excluded by mistake? -- Best regards, Aleksander Alekseev
Hi, On 2025-03-31 19:23:57 +0300, Aleksander Alekseev wrote: > Hi Andres, > > > aio: Add core asynchronous I/O infrastructure > > > > [...] > > I noticed that aio.c references README.md: > > ``` > * aio.c > * AIO - Core Logic > * > * For documentation about how AIO works on a higher level, including a > * schematic example, see README.md. > ``` > > However the file seems to be missing in this commit or in the > following ones. Any chance it was excluded by mistake? It'll be committed soon. There's one pending change in the README.md that I'd like to make / get comments on... Sorry for the temporarily "hanging" reference... Greetings, Andres