Greetings,
* Pól Ua Laoínecháin (linehanp@tcd.ie) wrote:
> > > 1) Is my lecturer full of it or does he really have a point?
>
> > He's full of it, as far as I can tell anyway, based on what you've
> > shared with us. Just look at the committers and the commit history to
> > PostgreSQL, and look at who the largest contributors are and who they
> > work for. That alone might be enough to surprise your lecturer with.
>
> The only non-PostgreSQL company that I could find was Fujitisu - where
> can I find a (list of) the others?
Not sure where you were looking... The contributors list is here:
https://www.postgresql.org/community/contributors/
The committers list is here:
https://wiki.postgresql.org/wiki/Committers
The git tree is here:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=summary
Perhaps not the best stat, but you can view the contributions by
committer pretty easily, for 2018, here:
https://github.com/postgres/postgres/graphs/contributors?from=2018-01-01&to=2018-12-31&type=c
Note that this isn't very representative of the actual authors though-
we don't track those in the way git would prefer, instead we note who
the author of a given patch was in the commit message itself.
> > Databases that do direct I/O don't depend on fsync. That said, I do
> > think this could have been an issue for Oracle if you ran it without
> > direct i/o.
>
> I think that Oracle are big into asyncio? I know that you have to sudo
> dnf install some_library with a name like asio/asyncio or something
> like that?
Oracle supports both, but running with direct i/o is pretty popular,
yes.
> Anyway, why doesn't PostgreSQL use Direct I/O?
There's an awful lot that the kernel provides when it comes to things
like good read-ahead and dealing with disks and SSDs and such that we
(currently, at least) prefer to leverage instead of writing lots of new
code to deal with that ourselves, which would be required to use Direct
I/O (and not have it be completely terrible performance wise, anyway).
The whole issue behind fsync was because our expectation (and POSIX's,
if you ask me anyway) was different from what the Linux kernel was
providing (specifically, you could end up in a situation where an
fsync() call "worked" and didn't return an error, even though there
remained pages that were dirty and not written out). Now, this is under
other error conditions typically and you'll get messages in the kernel
log about such failures usually, so if you're properly monitoring and
managing your systems there's a good chance you would have realized
there was a problem even though the Linux kernel was telling PG that
everything was fine (have backups!!).
Thanks,
Stephen