On 08.02.2013 06:59, Ilya Zverev wrote:
Though I fail to understand what would be broken if you continue to use
32-bit osm2pgsql. Indices, maybe.
don't be confused by the term 32-bit. It is required that the software
can handle 64-bit data types for processing the node id. In postgresql
it will be stored in a column declared as BIGINT.
Data types often are signed. So one of the 32 bits is used to store the
sign. The remaining 31 bits to store the ID are exhausted now.
Software can be compiled as a 32-bit or 64-bit executable. If you can,
you should use a 64-bit executable as this can access over 4GB of
memory, giving you the chance to speed up the import a lot.
What happens when you continue to use osm2pgsql with 32 bit ids (int4)
instead of int8?
Have a look at osmtypes.h. You'll see that osmid_t is declared as
int32_t which is signed:
typedef signed long int int32_t
So the value will overflow. In the best case osm2pgsql will abort with
an error. In the worst case your database content will be corrupted.
Your database structure still is only int4, again signed. So it all
needs to be converted into int8.
Probably easiest is to re-import into a fresh DB with 64-bit IDs. Most
people have done this step during the re-import after license change.
Stephan
_______________________________________________
dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/dev
