Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YiIAy-0004hx-Te for pgsql-committers@arkaria.postgresql.org; Wed, 15 Apr 2015 07:56:01 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YiIAy-00059L-3o for pgsql-committers@arkaria.postgresql.org; Wed, 15 Apr 2015 07:56:00 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YiIAx-00059E-3K for pgsql-committers@postgresql.org; Wed, 15 Apr 2015 07:55:59 +0000 Received: from mail-wg0-x233.google.com ([2a00:1450:400c:c00::233]) by magus.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1YiIAs-0003Et-9k; Wed, 15 Apr 2015 07:55:57 +0000 Received: by wgyo15 with SMTP id o15so37586678wgy.2; Wed, 15 Apr 2015 00:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DgAUjVYEKYHEXwwDX9DmR748ci1LPi5L4jRH6xOhuS0=; b=WiLzfs7TLrsrdDZf/r52wDIfP6LAWSpfN/Ns4sTFKB+7wXvihiC1MAjE0IzT3QGJiG qGssdkuvVLPHJYgqrwzvdzfLpBZBQbbZkq1RmV2AsvTVhbuo+lXRg3hBTG5PcokvX14v YWrVr2/K0fKapjD6BmyUr04pOIna82U7s64IT2fF/iwhaK/cG5tviy16fzPYK9F8U9TL yyWx+g2zsPtR6+96Dcx1aENWfv3gjEyfutr+uVwlbCcHLfO2FtV1wx+yR2bjH50Pl/W1 t0orvF3z2aocD+YiDOuI0WF3HowGKuFsDxLJ9G6s8BJp7ouWjJDhtMP4cIm7aZsTryIJ pG5Q== X-Received: by 10.194.200.194 with SMTP id ju2mr45860625wjc.61.1429084552958; Wed, 15 Apr 2015 00:55:52 -0700 (PDT) Received: from [192.168.1.99] (dsl-hkibrasgw1-58c38f-82.dhcp.inet.fi. [88.195.143.82]) by mx.google.com with ESMTPSA id k2sm6036543wif.3.2015.04.15.00.55.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Apr 2015 00:55:51 -0700 (PDT) Message-ID: <552E1985.1060202@iki.fi> Date: Wed, 15 Apr 2015 10:55:49 +0300 From: Heikki Linnakangas Reply-To: hlinnaka@iki.fi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0 MIME-Version: 1.0 To: Fujii Masao , Alvaro Herrera CC: Michael Paquier , Peter Eisentraut , Fujii Masao , pgsql-committers Subject: Re: pgsql: Mark the second argument of pg_log as the translatable string in References: <5529C5A7.3070708@gmx.net> <20150412011715.GK4369@alvh.no-ip.org> <20150413171705.GQ4369@alvh.no-ip.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.3 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-committers Precedence: bulk Sender: pgsql-committers-owner@postgresql.org On 04/15/2015 06:41 AM, Fujii Masao wrote: > On Tue, Apr 14, 2015 at 2:17 AM, Alvaro Herrera > wrote: >> Michael Paquier wrote: >>> On Sun, Apr 12, 2015 at 10:17 AM, Alvaro Herrera wrote: >>>> What pg_basebackup's progress_report() does is have the message in the >>>> translatable part not include the \r; the \r is in a separate fprintf() >>>> call. >>> >>> Like the attached then. >> >> Not a fan of this approach, because now this function knows that >> pg_log(PG_PROGRESS) is equivalent to printf(). This abstraction is a >> bit leaky, isn't it ... Probably not worth sweating about, though. >> >>> diff --git a/src/bin/pg_rewind/logging.c b/src/bin/pg_rewind/logging.c >>> index aba12d8..3e2dc76 100644 >>> --- a/src/bin/pg_rewind/logging.c >>> +++ b/src/bin/pg_rewind/logging.c >>> @@ -134,7 +134,8 @@ progress_report(bool force) >>> snprintf(fetch_size_str, sizeof(fetch_size_str), INT64_FORMAT, >>> fetch_size / 1024); >>> >>> - pg_log(PG_PROGRESS, "%*s/%s kB (%d%%) copied\r", >>> + pg_log(PG_PROGRESS, "%*s/%s kB (%d%%) copied", >>> (int) strlen(fetch_size_str), fetch_done_str, fetch_size_str, >>> percent); >>> + printf("\r"); >>> } > > So could you elaborate your "favorite" approach? > > Now pg_log() calls printf() and fflush(stdout). So '\r' is printed after fflush. > It's a bit strange. Maybe we can just replace pg_log() with printf() here. A better solution from a modularity point of view would be to add a new function, pg_progress() for this. It would print the line with pg_log() and then print the \r to the end. Then the caller wouldn't need to know whether the progress messages are going to stdout, stderr, or somewhere else entirely. > Another question is; should we output the progress report to stderr rather > than stdout? I thought this because I found that pg_basebackup reports > the progress to stderr. Yeah, probably. We should go through all the output and figure out where each kind of message needs to do. Should follow the principle Alvaro laid out (http://www.postgresql.org/message-id/20150407205320.GN4369@alvh.no-ip.org), and also make sure it's consistent with pg_basebackup and other tools. Michael's patch changed some of the logging but we should take a more holistic look at the situation. And add a comment somewhere explaining the principle. - Heikki -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers