pageserver: remove import/export script previously used for breaking format changes

[VladLazar]

Problem

The fullbackup command enabled us to do major storage format changes in the past.
If we have to do such breaking changes in the future this approach wouldn't be suitable because:

1. It doesn't scale to the current size of the fleet
2. It loses history

Summary of changes

Remove the fullbackup command handling and it's only user, the import/export script.

Note that I've kept the import basebackup and import wal commands since:

1. They enable a valid use case IMO: importing from a vanilla postgres instance (used by at least one test)
2. They enable the neon_local import command

Closes https://github.com/neondatabase/cloud/issues/11648

Checklist before requesting a review

• I have performed a self-review of my code.
• If it is a core feature, I have added thorough tests.
• Do we need to implement analytics? if so did you add the relevant metrics to the dashboard?
• If this PR requires public announcement, mark it with /release-notes label and add several sentences in this section.

Checklist before merging

• Do not forget to reformat commit message to not include the above checklist

[hlinnaka]

-1, it's very handy while debugging. @kelvich and I used it just last week when debugging a production issue. And we will eventually need the functionality for a user-exposed export feature. It was discussed as part of pg_upgrade, too.

I agree it's not how we'd want to do major storage format changes in the future. Some comment cleanup would be in order, to explain why the command still exists.

[hlinnaka]

It was discussed as part of pg_upgrade, too.

scratch that part, that was about the import function, not fullbackup

[github-actions]

2760 tests run: 2642 passed, 0 failed, 118 skipped (full report)

---

Code coverage* (full report)

• functions: 28.1% (6464 of 23041 functions)
• lines: 46.8% (45676 of 97593 lines)

* collected from Rust tests only

---

_{The comment gets automatically updated with the latest test results
7656930 at 2024-04-22T17:30:15.468Z :recycle:}

[VladLazar]

-1, it's very handy while debugging. @kelvich and I used it just last week when debugging a production issue.

Ok, let's leave it in that case. Did you use the export_import_between_pageservers.py script or did you do it manually? Trying to figure out what should stay and what's dead code.

[hlinnaka]

-1, it's very handy while debugging. @kelvich and I used it just last week when debugging a production issue.

Ok, let's leave it in that case. Did you use the export_import_between_pageservers.py script or did you do it manually? Trying to figure out what should stay and what's dead code.

I don't remember; @kelvich do you? The import part of the script certainly seems less interesting. And the add_missing_rels hack in the script seems obsolete for sure.

[kelvich]

I don't remember; @kelvich do you? The import part of the script certainly seems less interesting. And the add_missing_rels hack in the script seems obsolete for sure.

I usually use it manually: psql -c 'fullbackup <> <> <> <>' > backup.tar

[VladLazar]

I don't remember; @kelvich do you? The import part of the script certainly seems less interesting. And the add_missing_rels hack in the script seems obsolete for sure.

I usually use it manually: psql -c 'fullbackup <> <> <> <>' > backup.tar

Would be nice to have this procedure written down somewhere. The immediate next question is, what do you do with the fullbackup after you got it. I guess you'd use import basebackup if you wanted to load it into another pageserver.

[VladLazar]

Oke, so based on the feedback above, I will:

• remove the script
• update the comments around basebackup to make its purpose a bit clearer

[hlinnaka]

I checked if we still have test coverage for the fullbackup method; yes we do, tests test_import_from_pageserver_*.