On Nov 17, 2010, at 1:24 PM, Greg Smith wrote: > Scott Carey wrote: >> Did you recompile your test on the RHEL6 system? > > On both systems I showed, I checked out a fresh copy of the PostgreSQL > 9.1 HEAD from the git repo, and compiled that on the server, to make > sure I was pulling in the appropriate kernel headers. I wasn't aware of > exactly how the kernel sync stuff was refactored though, thanks for the > concise update on that.
Thanks! So this could be another bug in Linux. Not entirely surprising. Since fsync/fdatasync relative performance isn't similar to open_sync/open_datasync relative performance on this test there is probably a bug that either hurts fsync, or one that is preventing open_sync from dealing with metadata properly. Luckily for the xlog, both of those can be avoided -- the real choice is fdatasync vs open_datasync. And both work in newer kernels or break in certain older ones. > I can do similar tests on a RHEL5 system, but > not on the same hardware. Can only make my laptop boot so many > operating systems at a time usefully. Yeah, I understand. I might throw this at a RHEL5 system if I get a chance but I need one without a RAID card that is not in use. Hopefully it doesn't turn out that fdatasync is write-cache safe but open_sync/open_datasync isn't on that platform. It could impact the choice of a default value. > > -- > Greg Smith 2ndQuadrant US g...@2ndquadrant.com Baltimore, MD > PostgreSQL Training, Services and Support www.2ndQuadrant.us > "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books > -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
