Re: Direct I/O - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Direct I/O
Date
Msg-id 20230411015526.waz6bb3g43qmxovl@awork3.anarazel.de
Whole thread Raw
In response to Re: Direct I/O  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Direct I/O
List pgsql-hackers
Hi,

On 2023-04-10 19:27:27 +1200, Thomas Munro wrote:
> On Mon, Apr 10, 2023 at 2:57 PM Andres Freund <andres@anarazel.de> wrote:
> > Have you tried to write a reproducer for this that doesn't involve postgres?
> 
> I tried a bit.  I'll try harder soon.
> 
> > ... What kernel version did you repro
> > this on Thomas?
> 
> Debian's 6.0.10-2 kernel (Debian 12 on a random laptop).  Here's how I
> set up a test btrfs in case someone else wants a head start:
> 
> truncate -s2G 2GB.img
> sudo losetup --show --find 2GB.img
> sudo mkfs -t btrfs /dev/loop0 # the device name shown by losetup
> sudo mkdir /mnt/tmp
> sudo mount /dev/loop0 /mnt/tmp
> sudo chown $(whoami) /mnt/tmp
> 
> cd /mnt/tmp
> /path/to/initdb -D pgdata
> ... (see instructions further up for postgres command line + queries to run)

I initially failed to repro the issue with these instructions. Turns out that
the problem does not happen if huge pages are in used - I'd configured huge
pages, so the default huge_pages=try succeeded. As soon as I disable
huge_pages explicitly, it reproduces.

Another interesting bit is that if checksums are enabled, I also can't
reproduce the issue. Together with the huge_page issue, it does suggest that
this is somehow related to page faults. Which fits with the thread Andrea
referenced...

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Show various offset arrays for heap WAL records
Next
From: "Shinoda, Noriyoshi (PN Japan FSIP)"
Date:
Subject: RE: running logical replication as the subscription owner