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

[David Earl]

> >>> There are also some inconsistencies, where a field in one table has a
> >>> subtly different type to the corresponding field in another table (for
> >>> example gpx_id is something int(20) and sometimes bigint(64)).
> >>>
> >>> Some of the index choices look pretty dubious as well - not only does
> >>> current_segments not have a unique index on id, it has a 
> non-unique one
> >>> on id+visible which is a bit odd if id is supposed to be unique ;-)
> >> 
> >> I've been saying that for a while, but no one was listening...
> >
> > perhaps a specific patch with some background info to the list and cc to
> > SteveC would help? :-)
> 
> I did say I had started trying to write a patch... It's a bit
> complicated here though as will also need an SQL script to bring
> the server inline at a guess.


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.

I have no idea what the problem was, I've never looked at any of the internals of the server. But it could be

(a) the planet generation is wrong: there really isn't a duplicate id, it's just that the plant dump for some reason repeated a couple of segments. So, do the offending segments also exist as duplicates in the database?

(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?

(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.

(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.

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

David