Skip site navigation (1) Skip section navigation (2)

Re: Experimental patch for inter-page delay in VACUUM

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Experimental patch for inter-page delay in VACUUM
Date: 2003-11-05 01:26:02
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.


In response to


pgsql-hackers by date

Next:From: Greg StarkDate: 2003-11-05 01:32:59
Subject: Re: Open Sourcing pgManage
Previous:From: Andrew OverholtDate: 2003-11-05 01:05:00
Subject: make output

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group