Re: Direct I/O
Thomas Munro <thomas.munro@gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, Andrew Dunstan <andrew@dunslane.net>, Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>, Christoph Berg <myon@debian.org>, mikael.kjellstrom@gmail.com, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2023-04-14T23:16:57Z
Lists: pgsql-hackers
On Sat, Apr 15, 2023 at 7:38 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Andres Freund <andres@anarazel.de> writes: > > On 2023-04-14 15:21:18 -0400, Tom Lane wrote: > >> +1 for that, though. (Also, the fact that these animals aren't > >> actually failing suggests that 004_io_direct.pl needs expansion.) > > > It's skipped, due to lack of O_DIRECT: > > [20:50:22] t/004_io_direct.pl .............. skipped: no O_DIRECT > > Hmm, I'd say that might be just luck. Whether the compiler honors weird > alignment of locals seems independent of whether the OS has O_DIRECT. > > > So perhaps we don't even need a configure test, just a bit of ifdef'ery? It's > > a bit annoying structurally, because the PG*Aligned structs are defined in > > c.h, but the different ways of spelling O_DIRECT are dealt with in fd.h. > > > I wonder if we should try to move those structs to fd.h as well... > > I doubt they belong in c.h, so that could be plausible; except > I'm not convinced that testing O_DIRECT is sufficient. As far as I can tell, the failure to honour large alignment attributes even though the compiler passes our configure check that you can do that was considered to be approximately a bug[1] or at least a thing to be improved in fairly old GCC times but the fix wasn't back-patched that far. Unfortunately the projects that were allergic to the GPL3 change but wanted to ship a compiler (or some motivation related to that) got stuck on 4.2 for a while before they flipped to Clang (as OpenBSD has now done). It seems hard to get excited about doing anything about that on our side, and those systems are also spewing other warnings. But if we're going to do it, it looks like the right place would indeed be a new compiler check that the attribute exists *and* generates no warnings with alignment > 16, something like that? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16660
Commits
-
Rename hook functions for debug_io_direct to match variable name.
- 155c81463c26 16.0 landed
- 4f3514f201cf 17.0 landed
-
Rename io_direct to debug_io_direct.
- 319bae9a8da6 16.0 landed
-
Skip the 004_io_direct.pl test if a pre-flight check fails.
- 6ca8df2d6147 16.0 landed
-
Use higher wal_level for 004_io_direct.pl.
- 980e8879f54a 16.0 landed
-
Skip \password TAP test on old IPC::Run versions
- 2e57ffe12f6b 16.0 cited
-
Add io_direct setting (developer-only).
- d4e71df6d757 16.0 landed
-
Introduce PG_IO_ALIGN_SIZE and align all I/O buffers.
- faeedbcefd40 16.0 landed
-
Add palloc_aligned() to allow aligned memory allocations
- 439f61757f05 16.0 cited
-
initdb: When running CREATE DATABASE, use STRATEGY = WAL_COPY.
- ad43a413c4f7 15.0 cited