Date: Mon, 30 Mar 2020 22:40:14 -0700
From: Noah Misch <noah@leadboat.com>
To: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>,
	Amit Kapila <amit.kapila16@gmail.com>,
	David Steele <david@pgmasters.net>,
	Stephen Frost <sfrost@snowman.net>,
	Suraj Kharage <suraj.kharage@enterprisedb.com>,
	tushar <tushar.ahuja@enterprisedb.com>,
	Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>,
	Rushabh Lathia <rushabh.lathia@gmail.com>,
	Tels <nospam-pg-abuse@bloodgate.com>,
	Andrew Dunstan <andrew.dunstan@2ndquadrant.com>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
	Jeevan Chalke <jeevan.chalke@enterprisedb.com>,
	vignesh C <vignesh21@gmail.com>
Subject: Re: backup manifests
Message-ID: <20200331054014.GA3354091@rfd.leadboat.com>
References: <20200325205433.GV13712@tamriel.snowman.net>
 <CA+TgmoZcEXq0SUveFRbqrso1EsDKCn8YXPSyWJBhC-c3fDbO=Q@mail.gmail.com>
 <16538d02-fd4b-6c4f-81a5-132c8fe8c3e9@pgmasters.net>
 <CA+TgmoZfj3wqcgoaXp+4a7ZSk3coARcxvghT7m=7Hf=8r6st6w@mail.gmail.com>
 <20200329034010.GB2247658@rfd.leadboat.com>
 <CA+TgmobSzurSGzy4uLXq__h3pKFnb4RFHepa6yxs3h4d3gwGEg@mail.gmail.com>
 <20200330055854.GC2324620@rfd.leadboat.com>
 <CAA4eK1LiEwGtO7sq+6XeXGKTKgQi24uGqACfi5CQbj0nOYZ+gw@mail.gmail.com>
 <CA+TgmoZMMViAhhG8PywNHSPd3uENJwmGOX8KMoC+8dz=or5P+A@mail.gmail.com>
 <20200330191631.yjgvpdfd6u3raebw@alap3.anarazel.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200330191631.yjgvpdfd6u3raebw@alap3.anarazel.de>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk

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.