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.
