Re: Direct I/O

From: Andres Freund <andres(at)anarazel(dot)de>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Andrea Gelmini <andrea(dot)gelmini(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Noah Misch <noah(at)leadboat(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Direct I/O
Date: 2023-04-11 02:15:00
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On 2023-04-10 18:55:26 -0700, Andres Freund wrote:
> On 2023-04-10 19:27:27 +1200, Thomas Munro wrote:
> > On Mon, Apr 10, 2023 at 2:57 PM Andres Freund <andres(at)anarazel(dot)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...

The last iteration of the fix that I could find is:

And the fix has been merged into

I think that means it'll have to wait for 6.4 development to open (in a few
weeks), and then will be merged into the stable branches from there.


Andres Freund

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2023-04-11 02:31:40 Re: Direct I/O
Previous Message Shinoda, Noriyoshi (PN Japan FSIP) 2023-04-11 02:09:24 RE: running logical replication as the subscription owner