Greetings, * Pól Ua Laoínecháin (linehanp@xxxxxx) 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
Attachment:
signature.asc
Description: PGP signature
