no universally correct setting for fsync
in [PgSql]
|
From: Josh Berkus on 7 May 2010 13:56 > I never meant to suggest any statement in that section is factually > wrong; it's just all too rosy, leading people to believe it's no big > deal to turn it off. Yeah, that section is overdue for an update. I'll write some new text and post it to pgsql-docs. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bernd Helmle on 7 May 2010 19:32 --On 7. Mai 2010 09:48:53 -0500 Kevin Grittner <Kevin.Grittner(a)wicourts.gov> wrote: > I think it goes beyond "tweaking" -- I think we should have a bald > statement like "don't turn this off unless you're OK with losing the > entire contents of the database cluster." A brief listing of some > cases where that is OK might be illustrative. > +1 > I never meant to suggest any statement in that section is factually > wrong; it's just all too rosy, leading people to believe it's no big > deal to turn it off. I think one mistake in this paragraph is the passing mention of "performance". I've seen installations in the past with fsync=off only because the admin was pressured to get instantly "more speed" out of the database (think of "fast_mode=on"). In my opinion, phrases like "performance penalty" are misleading, if you need that setting in 99% of all use cases for reliable operation. I've recently even started to wonder if the performance gain with fsync=off is still that large on modern hardware. While testing large migration procedures to a new version some time ago (on an admitedly fast storage) i forgot here and then to turn it off, without a significant degradation in performance. -- Thanks Bernd -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 7 May 2010 19:49 Bernd Helmle <mailings(a)oopsware.de> writes: > I've recently even started to wonder if the performance gain with fsync=off > is still that large on modern hardware. While testing large migration > procedures to a new version some time ago (on an admitedly fast storage) i > forgot here and then to turn it off, without a significant degradation in > performance. That says to me either that you're using a battery-backed write cache, or your fsyncs don't really work (no write barriers or something like that). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bernd Helmle on 7 May 2010 20:16 --On 7. Mai 2010 19:49:15 -0400 Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Bernd Helmle <mailings(a)oopsware.de> writes: >> I've recently even started to wonder if the performance gain with >> fsync=off is still that large on modern hardware. While testing large >> migration procedures to a new version some time ago (on an admitedly >> fast storage) i forgot here and then to turn it off, without a >> significant degradation in performance. > > That says to me either that you're using a battery-backed write cache, > or your fsyncs don't really work (no write barriers or something like > that). > Well, yes, BBU present and proven storage. Maybe i'm wrong, but it seems battery backed write caches aren't that seldom even in low end systems nowadays. -- Thanks Bernd -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Craig Ringer on 8 May 2010 04:07
On 8/05/2010 1:56 AM, Josh Berkus wrote: > >> I never meant to suggest any statement in that section is factually >> wrong; it's just all too rosy, leading people to believe it's no big >> deal to turn it off. > > Yeah, that section is overdue for an update. I'll write some new text > and post it to pgsql-docs. It's probably worth mentioning that people who want to turn off fsync to gain a performance boost should instead look at a RAID controller with a BBU so they can safely enable write-back caching, getting most of the benefits of fsync=off safely. -- Craig Ringer -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |