From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: initdb -S and tablespaces |
Date: | 2015-05-09 02:08:31 |
Message-ID: | CA+TgmoZWaYy1pJO72vuKaiK4Q5FLLpyXEYRTedqtmAQQTcJ8Jw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, May 8, 2015 at 7:53 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2015-05-04 14:23:16 -0400, Robert Haas wrote:
>> On Fri, May 1, 2015 at 10:41 AM, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com> wrote:
>> > As for the non-backpatchable 0002, I agree with Andres that it should be
>> > included in 9.5; but I take it you're still not convinced?
>>
>> No, I'm not convinced. That patch will protect you in one extremely
>> specific scenario: you turn off fsync, do some stuff, shut down, turn
>> fsync back on again, and start up.
>
> Hm. ISTM it'd not be hard to actually make it safe in nearly all
> situations. What about tracking the last checkpoint's fsync setting and
> do a fsync_pgdata() in the checkpointer at the end of a checkpointer if
> the previous setting was off and the current one is on? Combined with
> doing so at startup if the settings changed between runs, that should
> give pretty decent protection. And seems fairly simple to implement.
That seems a bit better. I think it's really important, if we're
going to start to try to make fsync=off anything other than a toy,
that we document really clearly the circumstances in which it is or is
not safe:
- If you crash while fsync=off, your cluster may be corrupted.
- If you crash while fsync=on, but it was off at the last checkpoint,
your cluster may be corrupted.
- If you turn fsync=off, do stuff, turn fsync=on, and checkpoint
successfully, a subsequent crash should not corrupt anything.
Of course, even the last one isn't totally bullet-proof. Suppose one
backend fails to absorb the new setting for some reason...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-05-09 02:17:04 | Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API) |
Previous Message | Stephen Frost | 2015-05-09 01:24:41 | Re: Async execution of postgres_fdw. |