Andrew, * Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote: > On 03/22/2017 11:39 AM, Stephen Frost wrote: > > * Andrew Dunstan (and...@dunslane.net) wrote: > >> Sync pg_dump and pg_dumpall output > > This probably should have adjusted all callers of pg_dump in the > > regression tests to use the --no-sync option, otherwise we'll end up > > spending possibly a good bit of time calling fsync() during the > > regression tests unnecessairly. > > All of them? The imnpact is not likely to be huge in most cases > (possibly different on Windows). On crake, the bin-check stage actually > took less time after the change than before, so I suspect that the > impact will be pretty small.
Well, perhaps not all, but I'd think --no-sync would be better to have in most cases. We turn off fsync for all of the TAP tests and all initdb calls, so it seems like we should here too. Perhaps it won't be much overhead on an unloaded system, but not all of the buildfarm animals seem to be on unloaded systems, nor are they particularly fast in general or have fast i/o.. > Still I agree that we should have tests for both cases. Perhaps, though if I recall correctly, we've basically had zero calls for fsync() until this. If we don't feel like we need to test that in the backend then it seems a bit silly to feel like we need it for pg_dump's regression coverage. That said, perhaps the right answer is to have a couple tests for both the backend and for pg_dump which do exercise the fsync-enabled paths. Thanks! Stephen
signature.asc
Description: Digital signature
