Re: backup manifests
Noah Misch <noah@leadboat.com>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Try to avoid compiler warnings in optimized builds.
- 05021a2c0cd2 13.0 landed
-
Fix option related issues in pg_verifybackup.
- 0a89e93bfaa6 13.0 landed
-
Add index term for backup manifest in documentation.
- 4db819ba4039 13.0 landed
-
Code review for backup manifest.
- a2ac73e7be7a 13.0 landed
-
Document the backup manifest file format.
- 149f2ae88ab0 13.0 landed
-
Fix typo in pg_validatebackup documentation.
- c4f82a779d26 13.0 landed
-
Exclude backup_manifest file that existed in database, from BASE_BACKUP.
- 1ec50a81ec0a 13.0 landed
-
Msys2 tweaks for pg_validatebackup corruption test
- c3e4cbaab936 13.0 landed
-
Fix resource management bug with replication=database.
- 3e0d80fd8d3d 13.0 cited
-
Be more careful about time_t vs. pg_time_t in basebackup.c.
- db1531cae009 13.0 cited
-
pg_validatebackup: Fix 'make clean' to remove tmp_check.
- 9f8f881caa0f 13.0 landed
-
pg_validatebackup: Also use perl2host in TAP tests.
- 460314db08e8 13.0 landed
-
Generate backup manifests for base backups, and validate them.
- 0d8c9c1210c4 13.0 landed
-
Add checksum helper functions.
- c12e43a2e0d4 13.0 landed
-
pg_waldump: Add a --quiet option.
- ac44367efbef 13.0 landed
-
Catversion bump for b9b408c48724
- afb5465e0cfc 13.0 cited
-
pg_basebackup: Refactor code for reading COPY and tar data.
- 431ba7bebf13 13.0 landed
-
Use a ResourceOwner to track buffer pins in all cases.
- 3cb646264e8c 12.0 cited
-
Use ARMv8 CRC instructions where available.
- f044d71e331d 11.0 cited
-
Logical replication support for initial data copy
- 7c4f52409a8c 10.0 cited
-
Use Intel SSE 4.2 CRC instructions where available.
- 3dc2d62d0486 9.5.0 cited
-
Switch to CRC-32C in WAL and other places.
- 5028f22f6eb0 9.5.0 cited
-
Remove support for 64-bit CRC.
- 404bc51cde9d 9.5.0 cited
-
Change CRCs in WAL records from 64bit to 32bit for performance reasons.
- 21fda22ec46d 8.1.0 cited
On Mon, Mar 30, 2020 at 12:16:31PM -0700, Andres Freund wrote: > On 2020-03-30 15:04:55 -0400, Robert Haas wrote: > > I guess I'd like to be clear here that I have no fundamental > > disagreement with taking this tool in any direction that people would > > like it to go. For me it's just a question of timing. Feature freeze > > is now a week or so away, and nothing complicated is going to get done > > in that time. If we can all agree on something simple based on > > Andres's recent proposal, cool, but I'm not yet sure that will be the > > case, so what's plan B? We could decide that what I have here is just > > too little to be a viable facility on its own, but I think Stephen is > > the only one taking that position. We could release it as > > pg_validatemanifest with a plan to rename it if other backup-related > > checks are added later. We could release it as pg_validatebackup with > > the idea to avoid having to rename it when more backup-related checks > > are added later, but with a greater possibility of confusion in the > > meantime and no hard guarantee that anyone will actually develop such > > checks. We could put it in to pg_checksums, but I think that's really > > backing ourselves into a corner: if backup validation develops other > > checks that are not checksum-related, what then? I'd much rather > > gamble on keeping things together by topic (backup) than technology > > used internally (checksum). Putting it into pg_basebackup is another > > option, and would avoid that problem, but it's not my preferred > > option, because as I noted before, I think the command-line options > > will get confusing. > > I'm mildly inclined to name it pg_validate, pg_validate_dbdir or > such. And eventually (definitely not this release) subsume pg_checksums > in it. That way we can add other checkers too. Works for me; of those two, I prefer pg_validate.