Author: jburgess777[at]googlemail.com
[Added to the original trac issue at 9.07pm, Friday, 22nd February 2013]

I suspect you are using a 32 bit VM. It looks like the current code will fail to open a PBF file > 4GB when compiled as a 32 bit executable. It should be possible to fix this but importing a large amount of data on a 32 bit system is probably going to be slow.

I'll try to look at fixing this but in the short term you may be better off trying to run a 64 bit OS instead.

Author: errox
[Added to the original trac issue at 4.54pm, Sunday, 24th February 2013]

It has to be Possible with an 32 bit OS, too or not?

You are right, it is an 32 bit OS (Ubuntu with 5700 RAM -> VM) and 4 GB Swap.

If i use -1500 isnt he supposed to use only 1500 MB RAM?

Author: amm
[Added to the original trac issue at 5.42pm, Saturday, 2nd March 2013]

It looks like Ubuntu still does not default to using large file support[1] for their 32 bit OS version. So all of the file offset pointers are only 32 bit as well and thus can't handle large files.

It seems just adding a -D_FILE_OFFSET_BITS=64 to the compile flags might solve it. But as each OS and flavour seems to behave differently in this area, I am not sure what the best way to do this in configure is.

That said, even if you can open the file, you might well run into trouble later during the process on a 32 bit OS for such large imports, so I would definitely recommend using a 64 bit OS. Particularly if you say you have more than 4Gb of physical ram!

[1] http://sourceware.org/bugzilla/show_bug.cgi?id=13047

Author: pnorman
[Added to the original trac issue at 10.27am, Tuesday, 3rd January 2017]

We've dropped 32 bit support, so this no longer matters, and people are regularly using osm2pgsql with large files.