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: Manfred Spraul <manfred(at)colorfullife(dot)com>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: Experimental patch for inter-page delay in VACUUM
Date: 2003-11-05 06:06:09
Message-ID: 877k2f4aem.fsf@stark.dyndns.tv (view raw or flat)
Thread:
Lists: pgsql-hackers
Manfred Spraul <manfred(at)colorfullife(dot)com> writes:

> Greg Stark wrote:
> 
> >>>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:
> >

> At least Linux had one problem: fsync() syncs the inode to disk, but not the
> directory entry: if you rename a file, open it, write to it, fsync, and the
> computer crashes, then it's not guaranteed that the file rename is on the disk.
> I think only the old ext2 is affected, not the journaling filesystems.

That's true. But why would postgres ever have to worry about files being
renamed being synced? Tables and indexes don't get their files renamed
typically. WAL logs?

-- 
greg


In response to

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2003-11-05 07:01:25
Subject: Re: make output
Previous:From: Christopher Kings-LynneDate: 2003-11-05 06:02:48
Subject: weird regression test issue CVS HEAD

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