On Thu, Mar 23, 2017 at 1:10 AM, Stephen Frost <sfr...@snowman.net> wrote: > 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..
Agreed. >> 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. And agreed. The patch attached uses --no-sync in most places for pg_dump, except in 4 places of 002_pg_dump.pl to stress as well the sync code path. -- Michael
test-dump-nosync.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
