How does osm2pgsql --append handles duplicates while updating diff files

[wgds60]

If the changes.osc.gz file include e.g. osm_ids that are already in the database, how does osm2pgsql handle those updates?

Older versions (pre 0.9x e.g.?) had been throwing errors if an input file had duplicates (e.g. adding another region via --append instead of merging and deduplicating input files) if I remember this correctly.

But how does osm2pgsql e.g. handle the situation where a diff is applied for the last 12 hours while the db is only 4 hours behind?

[lonvia]

osm2pgsql will fail if (and only if) the same OSM object appears twice in the same input file. Otherwise in append mode the data in the database will be updated to whatever is in the file. If the data in the file is older than what is in the database, you do a 'rollback', i.e. you set the database to an older version. At this point there is no guarantee that the data is coherent up until you have reapplied all diffs up to the date where your database was before. This can be really useful, when something bad happened during updates. You can use the append mode to do a replay of updates. It is also useful after the initial import to make sure the data is properly in sync between your initial import source and your source of replication diffs.

If you use append mode to add more extracts to an existing database, it is your responsibility to make sure that the data in the database and the additional extract are exactly from the same date. Otherwise, again, there is no guarantee that the data is coherent.

[wgds60]

Thank you for your detailed reply. I was actually doing this:

It is also useful after the initial import to make sure the data is properly in sync between your initial import source and your source of replication diffs.

One last question regarding:

You can use the append mode to do a replay of updates.

Is there any performance degradation in replays of updates vs. normal updates?

[pnorman]

Potentially, but I doubt you'd notice it. With a replay, there is a guarantee that the DELETE statements will have rows to remove, which will take marginally longer.