no universally correct setting for fsync
in [PgSql]
|
From: Robert Haas on 7 May 2010 10:00 On Fri, May 7, 2010 at 9:47 AM, Kevin Grittner <Kevin.Grittner(a)wicourts.gov> wrote: > Someone just posted to the -admin list with a database corrupted > while running with fsync=off. I was all set to refer him to the > documentation explaining why he should stop doing this, but to my > surprise the documentation waffles on the issue way past what I > think is reasonable. > > http://www.postgresql.org/docs/8.4/interactive/runtime-config-wal.html#GUC-FSYNC > > There are dire-sounding statements interspersed with: > > | using fsync results in a performance penalty > > | Due to the risks involved, there is no universally correct setting > | for fsync. > > | If you trust your operating system, your hardware, and your > | utility company (or your battery backup), you can consider > | disabling fsync. > > Isn't this a little too rosy a picture to paint? I agree. I've always thought this part of the documentation made setting fsync=off much more reasonable than I feel it to be. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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: Magnus Hagander on 7 May 2010 10:03 On Fri, May 7, 2010 at 16:00, Robert Haas <robertmhaas(a)gmail.com> wrote: > On Fri, May 7, 2010 at 9:47 AM, Kevin Grittner > <Kevin.Grittner(a)wicourts.gov> wrote: >> Someone just posted to the -admin list with a database corrupted >> while running with fsync=off. I was all set to refer him to the >> documentation explaining why he should stop doing this, but to my >> surprise the documentation waffles on the issue way past what I >> think is reasonable. >> >> http://www.postgresql.org/docs/8.4/interactive/runtime-config-wal.html#GUC-FSYNC >> >> There are dire-sounding statements interspersed with: >> >> | using fsync results in a performance penalty >> >> | Due to the risks involved, there is no universally correct setting >> | for fsync. >> >> | If you trust your operating system, your hardware, and your >> | utility company (or your battery backup), you can consider >> | disabling fsync. >> >> Isn't this a little too rosy a picture to paint? > > I agree. I've always thought this part of the documentation made > setting fsync=off much more reasonable than I feel it to be. +1, definitely. fsync=off should only be done if you *really* understand what it means, and that requires a lot more explanation than that... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.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: Tom Lane on 7 May 2010 10:24 "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> writes: > | If you trust your operating system, your hardware, and your > | utility company (or your battery backup), you can consider > | disabling fsync. > Isn't this a little too rosy a picture to paint? I think that statement is true as far as it goes, but I agree with rejiggering the surrounding text. The whole thing was written back when Postgres was by far the least reliable component of the stack. It isn't anymore. We should make it clear that fsync=off is not ever recommended for production. 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: Andrew Dunstan on 7 May 2010 10:38 Kevin Grittner wrote: > > There are dire-sounding statements interspersed with: > > | using fsync results in a performance penalty > > | Due to the risks involved, there is no universally correct setting > | for fsync. > > | If you trust your operating system, your hardware, and your > | utility company (or your battery backup), you can consider > | disabling fsync. > > Isn't this a little too rosy a picture to paint? > > > I think the critical question is really whether you are prepared to lose your database. I have a customer who rotates databases in and out of line, and processes major updates on the out of line database. If they lose the database occasionally they are prepared to wear that risk for the performance gain they get from running with fsync off. It just means that they have to recover and so the inline database will get a bit staler than usual while they do. So I think its true that there is no universally right answer. Maybe the criteria mentioned in the last para need tweaking some, though. It's not just a matter of trusting hardware etc. I have seen mishaps when idiots knock out power cords and the like. The unexpected does sometime happen, despite the best planning. cheers andrew -- 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: "Kevin Grittner" on 7 May 2010 10:48 Andrew Dunstan <andrew(a)dunslane.net> wrote: > I think the critical question is really whether you are prepared > to lose your database. Precisely; and the docs don't make that at all clear. They mention the possibility of database corruption, but downplay it: | When fsync is disabled, the operating system is allowed to do its | best in buffering, ordering, and delaying writes. This can result | in significantly improved performance. However, if the system | crashes, the results of the last few committed transactions might | be lost in part or whole. In the worst case, unrecoverable data | corruption might occur. > [valid use case for fsync=off] > > So I think its true that there is no universally right answer. > Maybe the criteria mentioned in the last para need tweaking some, > though. 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. 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. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Next
|
Last
Pages: 1 2 3 4 5 6 Prev: [HACKERS] no universally correct setting for fsync Next: [HACKERS] beta to release |