Size and memory consumption of update packages vary greatly. While the preset 3600s-limit (configuration.txt) works well most of the time, some of the updates run out of memory (in my case 18GB allotted to Docker, using a 32GB swap on an SSD for a Europe-only server). Upon failing, the same update is attempted over and over again.
Suggestion: upon failure during osm2pgsql ("killed"), fall back to smaller chunks (e.g. 50%)
Another issue related to failure handling is, that if the container is stopped for any reason during an update, "state.txt" is left unchanged and therefore reflects the interrupted update as complete. Upon restart the subsequent update is started automatically, with unclear results (at best an incompletely updated database).
Suggestion: update "state.txt" only after successful import process
Size and memory consumption of update packages vary greatly. While the preset 3600s-limit (configuration.txt) works well most of the time, some of the updates run out of memory (in my case 18GB allotted to Docker, using a 32GB swap on an SSD for a Europe-only server). Upon failing, the same update is attempted over and over again.
Suggestion: upon failure during osm2pgsql ("killed"), fall back to smaller chunks (e.g. 50%)
Another issue related to failure handling is, that if the container is stopped for any reason during an update, "state.txt" is left unchanged and therefore reflects the interrupted update as complete. Upon restart the subsequent update is started automatically, with unclear results (at best an incompletely updated database).
Suggestion: update "state.txt" only after successful import process