Thread: 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.
Attachment
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