Обсуждение: Running with fsync=off

I want to be able to do large updates on an existing backed up database
with fsync=off but at the end of the updates how do I ensure that the
data gets synced?

Somebody said running "sync ; sync; sync" from the console.  This seems
reasonable but why not just "sync" or is there another command I should
ruyn after the update either in postgres or the console?

On Wed, Dec 21, 2005 at 11:30:15PM -0800, Benjamin Arai wrote:
> I want to be able to do large updates on an existing backed up database
> with fsync=off but at the end of the updates how do I ensure that the
> data gets synced?

Do you know if that actually makes it much faster? Maybe you're better
off splitting WAL into a seperate disk.

> Somebody said running "sync ; sync; sync" from the console.  This seems
> reasonable but why not just "sync" or is there another command I should
> ruyn after the update either in postgres or the console?

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.

Don't you need to restart postgres to change that parameter anyway?

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

Martijn van Oosterhout <kleptog@svana.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
happen.

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

On Thu, Dec 22, 2005 at 11:47:13AM -0500, Tom Lane wrote:
> Martijn van Oosterhout <kleptog@svana.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
> happen.
>
> 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.

How would sync<RETURN>sync<RETURN> differ from sync;sync? The second
case will wait for the first command to return, or is there a race
condition that's reduced by typing by hand?
--
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

"Jim C. Nasby" <jnasby@pervasive.com> writes:
> How would sync<RETURN>sync<RETURN> differ from sync;sync? The second
> case will wait for the first command to return, or is there a race
> condition that's reduced by typing by hand?

The actual runtime of the "sync" program is epsilon, because it doesn't
wait for all the I/O to happen.  The entire reason for the custom is
that the I/O is going on while you type the second "sync".  And yes,
it's a race condition.

            regards, tom lane

"Tom Lane" <tgl@sss.pgh.pa.us> wrote
>
> The actual runtime of the "sync" program is epsilon, because it doesn't
> wait for all the I/O to happen.  The entire reason for the custom is
> that the I/O is going on while you type the second "sync".

But in our 7.4.x, there is code like this:

 sync();
 if (IsUnderPostmaster)
  sleep(2);
 sync();

So for standalone backend, that's just "sync();sync()". So the "I/O is going
on while you type the second sync" theory doesn't work. For ordinary
backends, that's even more wierd - Why wasting 2 seconds is enough to save
the data? Why not 3 seconds or 4?

Regards,
Qingqing

"Qingqing Zhou" <zhouqq@cs.toronto.edu> writes:
> But in our 7.4.x, there is code like this:

>  sync();
>  if (IsUnderPostmaster)
>   sleep(2);
>  sync();

I'm not claiming that that code is correct; it is in fact just as broken
as the traditional custom.  You'll notice we don't have it anymore ;-)

> Why wasting 2 seconds is enough to save the data?

It's not.  The entire custom is and always has been bogus.

            regards, tom lane