Re: initdb -S and tablespaces
От | Abhijit Menon-Sen |
---|---|
Тема | Re: initdb -S and tablespaces |
Дата | |
Msg-id | 20150310074948.GA22050@toroid.org обсуждение исходный текст |
Ответ на | Re: initdb -S and tablespaces (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: initdb -S and tablespaces
|
Список | pgsql-hackers |
At 2015-01-15 14:32:45 +0100, andres@2ndquadrant.com wrote: > > 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. Patch attached. Changes: 1. Renamed perform_fsync to fsync_recursively (otherwise it would read "fsync_pgdata(pg_data)") 2. Added ControlData->fsync_disabled to record whether fsync was ever disabled while the server was running (tested in CreateCheckPoint) 3. Run fsync_recursively at startup only if fsync is enabled 4. Run it if we're doing crash recovery, or fsync was disabled 5. Use pg_flush_data in pre_sync_fname 6. Issue fsync on directories too 7. Tested that it works if pg_xlog is a symlink (no changes). (In short, everything you mentioned in your earlier mail.) Note that I set ControlData->fsync_disabled to false in BootstrapXLOG, but it gets set to true during a later CreateCheckPoint(). This means we run fsync again at startup after initdb. I'm not sure what to do about that. Is this about what you had in mind? -- Abhijit
Вложения
В списке pgsql-hackers по дате отправления: