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

From Abhijit Menon-Sen
Subject Re: initdb -S and tablespaces
Date
Msg-id 20150501032938.GA17628@toroid.org
Whole thread Raw
In response to Re: initdb -S and tablespaces  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: initdb -S and tablespaces  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
At 2015-04-30 15:37:44 -0400, robertmhaas@gmail.com wrote:
>
> 1. It doesn't do that.  As soon as we fsync the data directory, we
>    reset the flag.  That's not what "ever disabled" means to me.

Could you suggest an acceptable alternative wording? I can't immediately
think of anything better than "disabled since the last restart". That is
conditional on our resetting the flag, which we will do only if fsync is
enabled at startup. So it's true, but not the whole truth.

> 2. I don't know why it's part of this patch.

In 20150115133245.GG5245@awork2.anarazel.de, Andres explained his
rationale as follows:
   «What I am thinking of is that, currently, if you start the server   for initial loading with fsync=off, and then
restartit, you're open   to data loss. So when the current config file setting is changed   from off to on, we should
fsyncthe data directory. Even if there   was no crash restart.»
 

That's what I tried to implement.

> Also, it seems awfully unfortunate to me that we're duplicating a
> whole pile of code into xlog.c here.

I have pointed out and discussed the duplication several times. I did it
this way only because we were considering backporting the changes, and
at the time it seemed better to do this and fix the duplication in a
separate patch.

-- Abhijit



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: disallow operator "=>" and use it for named parameters
Next
From: Abhijit Menon-Sen
Date:
Subject: Re: initdb -S and tablespaces