tool: compaction log tool should be DB re-open aware

[nicktrav]

Consider the case where a JOB is printed in the logs with a relatively low job ID. If the the DB is restarted, the job ID counter is reset, which can result in IDs repeating themselves in the logs. This can throw off the tool, for example, by thinking that a compaction took longer than it really did.

Ideally, the tool would be "re-open aware", and would not attempt to combine jobs from either side of the boundary.

Jira issue: PEBBLE-93

[nicktrav]

One possible alternative that would solve this would be to have monotonically increasing Job IDs. That would necessitate some form of persistence, and it might not be worth the overhead if we can teach to tool how to handle the boundaries.

cc: @jbowens - not sure if the monotonic job IDs has come up before or if that would be useful for anything else.

[jbowens]

Good question re: unique job IDs. I don't think we'd want to actually persist each jobID to stable storage before using it, but maybe we could prefix job IDs with some ID representing the process run?

[darshanime]

but maybe we could prefix job IDs with some ID representing the process run?

ack, how about we initialize the jobId with os.Getpid() + 1?

pebble/open.go

Line 276 in f5d747d

d.mu.nextJobID = 1