[Tile-serving] [openstreetmap/osm2pgsql] 1.5.0 not all objects found in planet_osm_line/polygon in their full form (#1540)

[mboeringa]

@joto,

I am running into an issue with a **bad_alloc** with the data I am trying to process (67.3 GB Facebook Daylight). 

I am currently using a custom version of Paul's "flex version" of the openstreetmap-carto style (https://github.com/gravitystorm/openstreetmap-carto/pull/4431).

The main difference is that I de-activated second stage flex processing as needed for the admin boundaries stuff, and also the creation of the additional 'planet_osm_admin'/'planet_osm_transport_line'/'planet_osm_transport_polygon'/'planet_osm_route' tables, to reduce overhead in processing and RAM usage. Only the minimum 'planet_osm_point/line/polygon' tables will be created instead. 

- Note that I have used this custom version without issues on smaller extracts (tested multiple times)!
- Note also that I successfully imported the same extract using osm2pgsql v1.5.0 **before the fix** and using this style, _but with "--cache=0"_!

Now I initially ran out of RAM (110 GB available to Ubuntu VM), and the process got "killed" by Ubuntu. I than increased my swap space to 150 GB, and then get the "bad_alloc" message during way processing (tested twice).

Could this still be a memory issue? I would have expected the process to be killed when out of virtual memory, like the first time, but that clearly didn't happen.

Any other suggestions or comments regarding this specific error?

![afbeelding](https://user-images.githubusercontent.com/7635726/126479078-6cb34689-337e-4cb1-b2b5-98cfb7d9f144.png)


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/osm2pgsql/issues/1540#issuecomment-884115021
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tile-serving/attachments/20210721/2337a7ff/attachment.htm>