Re: Experimental patch for inter-page delay in VACUUM

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Greg Stark <gsstark(at)mit(dot)edu> writes:
> > Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> >> The main problem with this is knowing which files need to be fsync'd.
>
> > Why could the postmaster not just fsync *every* file?
>
> You want to find, open, and fsync() every file in the database cluster
> for every checkpoint? Sounds like a non-starter to me. In typical
> situations I'd expect there to be lots of files that have no writes
> during any given checkpoint interval (system catalogs for instance).

Except a) this is outside any critical path, and b) only done every few
minutes and c) the fsync calls on files with no dirty buffers ought to be
cheap, at least as far as i/o.

So even a few hundred extra open/fsync/close syscalls per minute wouldn't
really cause any extra i/o and wouldn't be happening frequently enough to use
any noticeable cpu.

> > I'm assuming fsync syncs writes issued by other processes on the same file,
> > which isn't necessarily true though.
>
> It was already pointed out that we can't rely on that assumption.

So the NetBSD and Sun developers I checked with both asserted fsync does in
fact guarantee this. And SUSv2 seems to back them up:

The fsync() function can be used by an application to indicate that all
data for the open file description named by fildes is to be transferred to
the storage device associated with the file described by fildes in an
implementation-dependent manner. The fsync() function does not return
until the system has completed that action or until an error is detected.

http://www.opengroup.org/onlinepubs/007908799/xsh/fsync.html

--
greg