Uses of the cache files when importing diffs

[Guy]

in the docs it says

"Each diff import requires access to the cache files from this initial import. So it is a good idea to set -cachedir to a premanent location instead of /tmp/."

Logically, I would expect that once a diff import has finished successfully, the new map representation is contained within the DB and would not require uses of any artifacts that were created.
For diff updates this would mean that any corruption in the cache files (but not in the DB, which is much more durable and resilient) would require to redo the entire process all over again - 

If there is only an initial osm.pdf file and a series of diffs, this would require to run them all, taking a long time 

I'd like to understand why and how the cache files are used in the diff (and initial import of the osm.pdf file with the -diff option) and whether it's possible to not use the cache files with degraded performance of importing

thanks

[Paul Norman]

On 2018-12-30 11:41 p.m., Guy wrote:
>
> I'd like to understand why and how the cache files are used in the
> diff (and initial import of the osm.pdf file with the -diff option)
> and whether it's possible to not use the cache files with degraded
> performance of importing

They're the equivalent of the osm2pgsql slim tables. They contain
additional information not contained in the database but needed for
updates, like way node membership.

If the files were lost you'd have to reimport, but you wouldn't reimport
the same file you started with, you'd import the current data so that
you don't have to do a bunch of updating.

[Guy]

In my case, I only have the initial osm.pbf and a series of diff files. I don't have the ability to obtain an intermediate osm.pbf file to be used for importing

is it possible to serialize the cache files and store them in the db?

since the db and cache files are currently decoupled, it means that restoring a DB would also need it's equivalent cache files at any given time :(