[OSM-dev] Planet OSM 'bad result during COPY'

[Seth Voltz]

Definitely worth checking out. When I setup the system I didn't install any of the CentOS Postgres packages and instead relied on the pgdg84 available ones.

-------------------------------
#> ldd /usr/local/bin/osm2pgsql | grep libpq
        libpq.so.5 => /usr/lib64/libpq.so.5 (0x00002aab6b07c000)
-------------------------------

Now for the embarrassing part. While the machine I'm running on has 16GB of RAM it lives in a virtual machine and it received a RAM cap of 372MB. Whoops. After finding the right logs to check (/var/log/pgsql is a red herring and I have a non-standard data directory location) all the problems were being caused by *massive* swapping and eventual shared memory allocation errors which stacked up until postgres just gave up the ghost and couldn't auto recover any more.

I asked our admin to bump me up to 8GB and the Austria import completed beautifully in only 6 minutes without even a hint of an error. As a comparison, it took 45 minutes before for Austria to fail. Postgres logs are clean as well.

I have started the planet import with --slim turned back on and will write back with how it works. My apologies for having missed this one. Also, you guys are lightning quick on the draw with really helpful questions and replies. Your help has been much appreciated!

— Seth

P.S. In the time it took to write up this email and verify I haven't missed anything else, I've pulled in 40000k points and eaten up 4GB of RAM. It's running quite a bit faster than I had expected.

On Apr 15, 2010, at 2:49 PM, Jon Burgess wrote:

> On Thu, 2010-04-15 at 14:24 -0700, Seth Voltz wrote:
>> Jon and Frederik: good hunch, the Austrian import failed with:
>> 
>> 
>> --------------------------------
>> #> osm2pgsql --database world --username gis --password --verbose
>> austria.osm.bz2
>> ... (cut) ...
>> Reading in file: austria.osm.bz2
>> Processing: Node(6760k) Way(0k) Relation(0k)planet_osm_point - bad
>> result during COPY, data 430058975   \N      \N      \N      \N
>> \N      \N      \N      \N      \N      \N      \N      \N      \N
>>   \
>> N       \N      \N      \N      \N      \N      \N      \N
>> bus_stop        \N      \N      \N      \N      \N      \N      \N
>>   \N      \N      \N      \N      Altöttinger Straße/Aldi \N      \N
>>     \
>> N       \N      \N      \N      \N      \N      \N      \N      \N
>>   \N      \N      \N      \N      \N      \N      \N      \N      \N
>>     \N      SRID=900913;POINT(1398018.41536173 6112460.23312236)
>> ... (cut) ...
>> --------------------------------
>> 
>> 
>> I double checked the database: everything, including my GIS templates
>> and the working database are UTF8:
>> 
>> 
>> --------------------------------
>> #> psql -U gis -l
>> ... (cut) ...
>> world            | gis      | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
>> --------------------------------
>> 
>> 
>> Also, I just noticed that when it fails it also crashes the whole
>> PostgreSQL server requiring a `service postgresql restart` to get
>> going again. This started when I began using the --verbose switch.
>> Failed imports with and without --slim and without --verbose just fail
>> but leave the database alone.
> 
> Anything which crashes the database backend sounds more like an issue in
> Postgresql rather than osm2pgsql.
> 
> One thing you might want to try is to recompile osm2pgsql against the
> PostgreSQL-8.4 client library. There is a good chance that a binary
> built in the normal way will be linking against the standard system
> library (probably /usr/lib/libpq.so.4) not the postgresql-8.4 (probably
> libpq.5 somewhere). 
> 
> To find out the library it is using try:
> $ ldd ~/bin/osm2pgsql | grep libpq
>        libpq.so.5 => /usr/lib64/libpq.so.5 (0x00007f6311499000)
> 
> The above output is from a F-12 system using PostgreSQL-8.4.3
> 
> You will need to install the pgdg postgresql-devel package and maybe
> tweak the include path in the Makefile to pick up the right version when
> you recompile.
> 
> 
>> 
>> The log file in /var/log/pgsql is empty (0 bytes).
>> 
>> 
>> Matt & Peter: good catch, it was a typo. I have 8.4.3 from the pgdg84
>> repository which I setup with:
>> 
>> 
>> --------------------------------
>> #> rpm -ivh
>> http://yum.pgsqlrpms.org/reporpms/8.4/pgdg-centos-8.4-2.noarch.rpm
>> --------------------------------
>> 
>> 
>> 
>> — Seth
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20100415/16cf7627/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20100415/16cf7627/attachment.pgp>