Opened 10 years ago
Closed 7 years ago
#1230 closed defect (fixed)
Postgres Disk Activity on Boot
|Reported by:||darkblueb||Owned by:|
During testing of Live 7.0 RC2, it was noticed that there is some non-trivial disk activity by postgresql at boot time..
With some research, I have found that .. if we do not stop postgres before taking the final disk image... then on start the postgres cluster will do "WAL recovery" .. basically making things match to where it left off..
It is possible that adding a simple stop before imaging the Live could have benefits
Change history (8)
comment:1 by , 10 years ago
comment:2 by , 9 years ago
retest in 7.9b
comment:3 by , 9 years ago
comment:4 by , 9 years ago
mysql and postgres services stopped in setdown.sh with r10829.
need to test on a usb with persistent filesystem to see how well it (and VACUUM at the end of db creating scripts) worked. If it didn't work well the first boot should be very slow on USB2 as it blocks due to all the usb-disk i/o, and mounting the overlay filesystem from another booted linux system should show lots of space used by the postgres db files.
comment:5 by , 9 years ago
still lots written to pg and mysql dbs on first boot.
not sure why
one persistent usb boot, wait, shutdown, then mount -o loop the casper-rw filesystem on another linux system. only new files will be there, about 111mb right now.
comment:6 by , 9 years ago
|Milestone:||OSGeoLive7.9 → OSGeoLive8.0|
comment:7 by , 7 years ago
|Type:||enhancement → defect|
Is this still an issue?
comment:8 by , 7 years ago
|Status:||new → closed|
looks like a clean boot in
/var/lib/postgresql/9.5/main dirs -- closing this ticket.
Nicely spotted Brian. So I guess to "service postgresql stop" in setdown.sh?
(for mysql too? that seems to be writing at boot time as well)
anything else that want's to be closed cleanly before assuming a crash on reboot?