Duplicate L1 generation

[koivunej]

#4088 was closed via the fix to get silently rid of it, we should still overwrite existing.

After looking at the metadata updates in https://github.com/neondatabase/neon/pull/5074/files#r1302831422 thought that we should track the most recent L0->L1 compaction LSN. As in, after Timeline::compact_level0 finishes, we would be in a state where we would only consider deleting the "input L0"'s.

I wonder if we would have to define last_compact_l0 as something which can be reset if we fail to upload L1's and still have the L0's? The last_compact_l0 would be beneficial for tests as well, currently we do sleep + wait_for_uploads.

This has most likely been discussed already, but I don't remember having seen any of that.

[jcsp]

This is probably no longer relevant now that we reset from remote storage on startup; feel free to re-open if there is still an issue here.

[koivunej]

Let's just reopen this as it is still relevant.

[jcsp]

What's the distinction between #7790 and this issue?

As I understand the status from that issue:

• We don't have any known issues in prod where we would generate duplicate layers
• We have some tests that do failure injection in a way that can generate duplicate layers (because they do return Ok(()) in places they shouldn't)
• Current WiP tiered compaction code has a bug where it can emit duplicate layers.

[koivunej]

It can very much happen, but it has not. Well, I guess we can handle that on #7790 as well.