John Spray b4e00b8b22 pageserver: refuse to load tenants with suspiciously old indices in old generations (#9719) ...

## Problem

Historically, if a control component passed a pageserver "generation: 1"
this could be a quick way to corrupt a tenant by loading a historic
index.

Follows https://github.com/neondatabase/neon/pull/9383
Closes #6951 

## Summary of changes

- Introduce a Fatal variant to DownloadError, to enable index downloads
to signal when they have encountered a scary enough situation that we
shouldn't proceed to load the tenant.
- Handle this variant by putting the tenant into a broken state (no
matter which timeline within the tenant reported it)
- Add a test for this case

In the event that this behavior fires when we don't want it to, we have
ways to intervene:
- "Touch" an affected index to update its mtime (download+upload S3
object)
- If this behavior is triggered, it indicates we're attaching in some
old generation, so we should be able to fix that by manually bumping
generation numbers in the storage controller database (this should never
happen, but it's an option if it does)

2024-11-13 18:07:39 +00:00

..

src

pageserver: refuse to load tenants with suspiciously old indices in old generations (#9719)

2024-11-13 18:07:39 +00:00

tests

storage_controller: delete stale shards when deleting tenant (#9333)

2024-10-17 14:34:51 +00:00

Cargo.toml

refactor(pageserver): upgrade remote_storage to use hyper1 (#9405)

2024-10-16 16:19:45 +01:00