Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h4m6c-0002Mb-QG for pgsql-hackers@arkaria.postgresql.org; Fri, 15 Mar 2019 12:38:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h4m5c-0001ab-JV for pgsql-hackers@arkaria.postgresql.org; Fri, 15 Mar 2019 12:37:32 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h4m5c-0001We-AS for pgsql-hackers@lists.postgresql.org; Fri, 15 Mar 2019 12:37:32 +0000 Received: from gauss.credativ.com ([93.94.130.89]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h4m5Z-0007UO-Eu for pgsql-hackers@lists.postgresql.org; Fri, 15 Mar 2019 12:37:31 +0000 Received: from gauss.credativ.com (localhost [127.0.0.1]) by gauss.credativ.com (Postfix) with ESMTP id BAB351E39E8; Fri, 15 Mar 2019 13:37:28 +0100 (CET) Received: from kohn.fritz.box (ppp-188-174-36-161.dynamic.mnet-online.de [188.174.36.161]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mba@gauss.credativ.com) by gauss.credativ.com (Postfix) with ESMTPSA id 59D7E1E28B8; Fri, 15 Mar 2019 13:37:28 +0100 (CET) Message-ID: <1552653447.9697.24.camel@credativ.de> Subject: Re: Offline enabling/disabling of data checksums From: Michael Banck To: Michael Paquier Cc: Magnus Hagander , Fabien COELHO , Sergei Kornilov , PostgreSQL Developers Date: Fri, 15 Mar 2019 13:37:27 +0100 In-Reply-To: <20190315122309.GA1434@paquier.xyz> References: <20190313093150.GE2988@paquier.xyz> <1552473675.4947.62.camel@credativ.de> <1552475364.4947.64.camel@credativ.de> <20190313115633.GA1878@paquier.xyz> <20190314043936.GH3493@paquier.xyz> <1552577180.9697.4.camel@credativ.de> <20190315025027.GN3493@paquier.xyz> <1552650841.9697.22.camel@credativ.de> <20190315122309.GA1434@paquier.xyz> Organization: credativ GmbH Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6-1+deb9u1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, Am Freitag, den 15.03.2019, 21:23 +0900 schrieb Michael Paquier: > On Fri, Mar 15, 2019 at 12:54:01PM +0100, Michael Banck wrote: > > 1. There's a typo in line 578 which makes it fail to compile: > > > > > src/bin/pg_checksums/pg_checksums.c:578:4: error: ‘y’ undeclared (first use in this function) > > > }y > > I am wondering where you got this one. My local branch does not have > it, and the patch I sent does not seem to have it either. Mea culpa, I must've fat fingered something in the editor before applying your patch, sorry. I should've double-checked. > > 2. Should the pqsignal() stuff only be setup in PG_MODE_ENABLE? Same > > with the controlfile_path? > > PG_MODE_DISABLE needs controlfile_path as well. We could make the > cleanup only available when using --enable, the code just looked more > simple in its current shape. I think it's just more simple to set > everything unconditionally. This code may become more complicated in > the future. Ok. > > 3. There's (I think) leftover debug output in the following places: > > > > > + printf(_("Renaming \"%s\" to \"%s\"\n"), controlfile_path, > > > + controlfile_path_temp); > > > + printf(_("Renaming \"%s\" to \"%s\"\n"), controlfile_path_temp, > > > + controlfile_path); > > > + printf(_("Syncing data folder\n")); > > > > (that one is debatable, we are mentioning this only in verbose mode in > > pg_basebackup but pg_checksums is more chatty anyway, so probably > > fine). > > This is wanted. Many folks have been complaning on this thread about > crashes and such, surely we want logs about what happens :) > > > > + printf(_("Updating control file\n")); > > > > Besides to the syncing message (which is user-relevant cause they might > > wonder what is taking so long), the others seem to be implementation > > details we don't need to tell the user about. > > Perhaps having them under --verbose makes more sense? Well if we think it is essential in order to tell the user what happened in the case of an error, it shouldn't be verbose I guess. Michael -- Michael Banck Projektleiter / Senior Berater Tel.: +49 2166 9901-171 Fax: +49 2166 9901-100 Email: michael.banck@credativ.de credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer Unser Umgang mit personenbezogenen Daten unterliegt folgenden Bestimmungen: https://www.credativ.de/datenschutz