Re: Raw device on PostgreSQL

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
Cc: Andreas Karlsson <andreas(at)proxel(dot)se>, Benjamin Schaller <benjamin(dot)schaller(at)s2018(dot)tu-chemnitz(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Raw device on PostgreSQL
Date: 2020-05-01 20:58:36
Message-ID: CA+hUKG+Vy+d47wqcNkKnGCiis581SM6dz-0vevSH4V44P_AhZw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, May 1, 2020 at 12:28 PM Jonah H. Harris <jonah(dot)harris(at)gmail(dot)com> wrote:
> Also, this will likely have an issue with O_DIRECT as additional buffer manager alignment is needed and I haven't tracked it down in 13 yet. As my default development is on a Mac, I have POSIX AIO only. As such, I can't natively play with the O_DIRECT or libaio paths to see if they work without going into Docker or VirtualBox - and I don't care that much right now :)

Andres is prototyping with io_uring, which supersedes libaio and can
do much more stuff, notably buffered and unbuffered I/O; there's no
point in looking at libaio. I agree that we should definitely support
POSIX AIO, because that gets you macOS, FreeBSD, NetBSD, AIX, HPUX
with one effort (those are the systems that use either kernel threads
or true async I/O down to the driver; Solaris and Linux also provide
POSIX AIO, but it's emulated with user space threads, which probably
wouldn't work well for our multi process design). The third API that
we'd want to support is Windows overlapped I/O with completion ports.
With those three APIs you can hit all systems in our build farm except
Solaris and OpenBSD, so they'd still use synchronous I/O (though we
could do our own emulation with worker processes pretty easily).

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jonah H. Harris 2020-05-01 21:00:55 Re: Raw device on PostgreSQL
Previous Message Robert Haas 2020-05-01 20:32:15 Re: design for parallel backup