Re: Direct I/O

From: Andres Freund <andres(at)anarazel(dot)de>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, Christoph Berg <myon(at)debian(dot)org>, mikael(dot)kjellstrom(at)gmail(dot)com, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Direct I/O
Date: 2023-04-19 17:13:55
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On 2023-04-18 15:35:09 -0400, Greg Stark wrote:
> On Mon, 17 Apr 2023 at 17:45, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> > It's something you'd
> > opt into for a dedicated database server along with other carefully
> > considered settings. It seems acceptable to me that if you set
> > io_direct to a non-default setting on an unusual-for-a-database-server
> > filesystem you might get errors screaming about inability to open
> > files -- you'll just have to turn it back off again if it doesn't work
> > for you.
> If the only solution is to turn it off perhaps the server should just
> turn it off? I guess the problem is that the shared_buffers might be
> set assuming it would be on?

I am quite strongly opposed to that - silently (or with a log message, which
practically is the same as silently) disabling performance relevant options
like DIO is much more likely to cause problems, due to the drastically
different performance characteristics you get. I can see us making it
configurable to try using DIO though, but I am not convinced it's worth
bothering with that. But we'll see.


Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2023-04-19 17:16:24 Re: Wrong results from Parallel Hash Full Join
Previous Message Andres Freund 2023-04-19 17:10:13 Re: Direct I/O