Horton

Re: Direct I/O

Thomas Munro <thomas.munro@gmail.com>

View thread View on postgr.es
From: Thomas Munro <thomas.munro@gmail.com>
To: Christoph Berg <myon@debian.org>, Thomas Munro <thomas.munro@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2023-04-12T03:04:16Z
Lists: pgsql-hackers 
On Wed, Apr 12, 2023 at 2:56 PM Christoph Berg <myon@debian.org> wrote:
> I'm hitting a panic in t_004_io_direct. The build is running on
> overlayfs on tmpfs/ext4 (upper/lower) which is probably a weird
> combination but has worked well for building everything over the last
> decade. On Debian unstable:
>
> PANIC:  could not open file "pg_wal/000000010000000000000001": Invalid argument

Hi Christoph,

That's an interesting one.  I was half expecting to see that on some
unusual systems, which is why I made the test check which OS it is and
exclude those that are known to fail with EINVAL or ENOTSUPP on their
common/typical file systems.  But if it's going to be Linux, that's
not going to work.  I have a new idea:  perhaps it is possible to try
to open a file with O_DIRECT from perl, and if it fails like that,
skip the test.  Looking into that now.

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.