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

Re: Experimental patch for inter-page delay in VACUUM

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jan Wieck <JanWieck(at)Yahoo(dot)com>,Ang Chin Han <angch(at)bytecraft(dot)com(dot)my>,Christopher Browne <cbbrowne(at)acm(dot)org>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Experimental patch for inter-page delay in VACUUM
Date: 2003-11-04 20:41:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, 4 Nov 2003, Tom Lane wrote:

> Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> > What still needs to be addressed is the IO storm cause by checkpoints. I 
> > see it much relaxed when stretching out the BufferSync() over most of 
> > the time until the next one should occur. But the kernel sync at it's 
> > end still pushes the system hard against the wall.
> I have never been happy with the fact that we use sync(2) at all.  Quite
> aside from the "I/O storm" issue, sync() is really an unsafe way to do a
> checkpoint, because there is no way to be certain when it is done.  And
> on top of that, it does too much, because it forces syncing of files
> unrelated to Postgres.
> I would like to see us go over to fsync, or some other technique that
> gives more certainty about when the write has occurred.  There might be
> some scope that way to allow stretching out the I/O, too.
> The main problem with this is knowing which files need to be fsync'd.

Wasn't this a problem that the win32 port had to solve by keeping a list 
of all files that need fsyncing since Windows doesn't do sync() in the 
classical sense?  If so, then could we use that code to keep track of the 
files that need fsyncing?

In response to


pgsql-hackers by date

Next:From: Marc G. FournierDate: 2003-11-04 20:59:57
Subject: Re: Open Sourcing pgManage
Previous:From: Jan WieckDate: 2003-11-04 20:39:51
Subject: Re: Experimental ARC implementation

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