On 2015-01-15 11:02:43 +0530, Abhijit Menon-Sen wrote:
> At 2015-01-14 11:59:08 +0100, andres@2ndquadrant.com wrote:
> >
> > > + if (ControlFile->state != DB_SHUTDOWNED &&
> > > + ControlFile->state != DB_SHUTDOWNED_IN_RECOVERY)
> > > + perform_fsync(data_directory);
> > > +
> >
> > a) Please think of a slightly more descriptive name than perform_fsync
>
> OK. (I just copied the name initdb uses, because at the time I was still
> thinking in terms of a later patch moving this to src/common.) What do
> you think of fsync_recursively? fsync_pgdata?
I like fsync_pgdata/datadir or something.
Note that I think you'll have to check/handle pg_xlog being a symlink -
we explicitly support that as a usecase...
> > c) I'm wondering if we should add fsync to the control file and also
> > perform an fsync if the last shutdown was clear, but fsync was
> > disabled.
>
> Explain? "Add fsync to the control file" means store the value of the
> fsync GUC setting in the control file?
Yes.
> And would the fsync you mention be dependent on the setting, or unconditional?
What I am thinking of is that, currently, if you start the server for
initial loading with fsync=off, and then restart it, you're open to data
loss. So when the current config file setting is changed from off to on,
we should fsync the data directory. Even if there was no crash restart.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services