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

Re: [GENERAL] Running with fsync=off

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Benjamin Arai <barai(at)cs(dot)ucr(dot)edu>, pgsql-admin(at)postgresql(dot)org, pgsql-general(at)postgresql(dot)org
Subject: Re: [GENERAL] Running with fsync=off
Date: 2005-12-22 16:47:13
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-adminpgsql-general
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> On Wed, Dec 21, 2005 at 11:30:15PM -0800, Benjamin Arai wrote:
>> Somebody said running "sync ; sync; sync" from the console.  This seems

> The reason is partly historical. On some OSes running sync only starts
> the process but returns immediatly. However, there can only be one sync
> at a time so the second sync waits for the first the finish. The third
> is just for show. However, on Linux at least the one sync is enough.

No, the second and third are both a waste of time.  sync tells the
kernel to flush any dirty buffers to disk, but doesn't wait for it to

There is a story that the advice to type sync twice was originally given
to operators of an early Unix system, as a quick-and-dirty way of making
sure that they didn't power the machine down before the sync completed.
I don't know if it's true or not, but certainly the value would only
appear if you type sync<RETURN>sync<RETURN> so that the first sync is
actually issued before you type the next one.  Typing them all on one
line as depicted is just a waste of finger motion.

			regards, tom lane

In response to


pgsql-admin by date

Next:From: Tom LaneDate: 2005-12-22 16:53:01
Subject: Re: Pgstat.tmp file activity
Previous:From: Alain Rodriguez AriasDate: 2005-12-22 15:30:56
Subject: Re: file in posgres

pgsql-general by date

Next:From: Carlos MorenoDate: 2005-12-22 16:52:47
Subject: Why is create function bringing down the Backend server?
Previous:From: Bruce MomjianDate: 2005-12-22 16:33:32
Subject: Re: About Maximum number of columns

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