Re: initdb -S and tablespaces - Mailing list pgsql-hackers

From Robert Haas
Subject Re: initdb -S and tablespaces
Date
Msg-id CA+TgmoYhCJzNt4gyPfw05H_e0H7kMPpy7g_PnCiP_WjgaEd7MA@mail.gmail.com
Whole thread Raw
In response to Re: initdb -S and tablespaces  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
Responses Re: initdb -S and tablespaces  (David Rowley <dgrowleyml@gmail.com>)
Re: initdb -S and tablespaces  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Fri, May 1, 2015 at 10:41 AM, Abhijit Menon-Sen <ams@2ndquadrant.com> wrote:
> At 2015-05-01 09:57:28 -0400, robertmhaas@gmail.com wrote:
>>
>> If you don't object to this version, I'll commit it.
>
> Looks fine to me, thank you.

OK, committed and back-patched.

> 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.  But it won't protect you if you
crash while fsync is off, or after you shut down with fsync=off and
before you restart with fsync=on.  And there's no documentation change
here that would help anyone distinguish between the situations in
which they are protected and the situations in which they are not
protected.  Without that, a lot of people are going to get this wrong.

As an alternative, how about fsync=shutdown parameter?  This could be
documented to fsync the data directory at shutdown.  It could document
that there is a risk of corruption if the server crashes, but that the
database is OK if shut down cleanly.  fsync=off could document that
you must run initdb --sync-only after shutting down, else you are
unsafe.

I'm not wedded to any particular solution, but an undocumented hack
that some people will manage to use safely some of the time doesn't
seem good enough to me.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: BUG in XLogRecordAssemble
Next
From: Alvaro Herrera
Date:
Subject: Re: deparsing utility commands