[OSM-dev] [OSM-talk] Oh dear - planet has duplicate id's

Martijn van Oosterhout kleptog at gmail.com
Thu May 31 20:09:42 BST 2007

On 5/31/07, David Earl <david at frankieandshadow.com> wrote:
> Fixing the schema is clearly desirable, but what it will do is make something blow up with an SQL that doesn't at present. But finding out how someone came to attempt to create a duplicate id is as important IMO.

But data integrity is paramount. We have to prevent bad data getting
in, and having the server crash when it tries is absolutly acceptable.

> (b) did some tool provide the offending ids like that, and if so why did the server accept them? Which tool, and who needs to fix it?

Either. But the database should have refused anyway.

> (c) Or is the server logioc wrong, perhaps encountering an exisiting id is supposed to treat it as an update to the segment when in fact it was handled incorrectly as an insert. That would be a major bug if so, threatening the whole integrity of the data.

Possibly. But the database should refuse anyway.

> (d) or maybe there is a timing problem whereby two clients trying to add segments at the same time get allocated the same id. Again, major integrity problem.

This is my guess. And this is what databases are optimised for. There
is *no* reason to bother checking this in the ruby code. The database
is going to do it a million times more efficiently.

> Finding the root cause of the problem seems like the most important activity IMO.

Yep, and having the database raise a red flag when it happens is by
far the easiest way.

Have a ncie day,
Martijn van Oosterhout <kleptog at gmail.com> http://svana.org/kleptog/

More information about the dev mailing list