Horton

Re: Direct I/O

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Thomas Munro <thomas.munro@gmail.com>, 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-17T15:44:45Z
Lists: pgsql-hackers 
On Sat, Apr 15, 2023 at 2:19 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I get the impression that we are going to need an actual runtime
> test if we want to defend against this.  Not entirely convinced
> it's worth the trouble.  Who, other than our deliberately rear-guard
> buildfarm animals, is going to be building modern PG with such old
> compilers?  (And more especially to the point, on platforms new
> enough to have working O_DIRECT?)

I don't think that I fully understand everything under discussion
here, but I would just like to throw in a vote for trying to make
failures as comprehensible as we reasonably can. It makes me a bit
nervous to rely on things like "anybody who has O_DIRECT will also
have working alignment pragmas," because there's no relationship
between those things other than when we think they got implemented on
the platforms that are popular today. If somebody ships me a brand new
Deathstation 9000 that has O_DIRECT but NOT alignment pragmas, how
badly are things going to break and how hard is it going to be for me
to understand why it's not working?

I understand that nobody (including me) wants the code cluttered with
a bunch of useless cruft that caters only to hypothetical systems, and
I don't want us to spend a lot of effort building untestable
infrastructure that caters only to such machines. I just don't want us
to do things that are more magical than they need to be. If and when
something fails, it's real nice if you can easily understand why it
failed.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

Commits

  1. Rename hook functions for debug_io_direct to match variable name.

  2. Rename io_direct to debug_io_direct.

  3. Skip the 004_io_direct.pl test if a pre-flight check fails.

  4. Use higher wal_level for 004_io_direct.pl.

  5. Skip \password TAP test on old IPC::Run versions

  6. Add io_direct setting (developer-only).

  7. Introduce PG_IO_ALIGN_SIZE and align all I/O buffers.

  8. Add palloc_aligned() to allow aligned memory allocations

  9. initdb: When running CREATE DATABASE, use STRATEGY = WAL_COPY.