Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qQrZY-001DKx-OW for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Aug 2023 15:46:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qQrZU-007q4a-TN for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Aug 2023 15:46:06 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qQrZU-007q4S-K6 for pgsql-hackers@lists.postgresql.org; Tue, 01 Aug 2023 15:46:06 +0000 Received: from mail-pl1-x62d.google.com ([2607:f8b0:4864:20::62d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qQrZP-000CnE-4U for pgsql-hackers@postgresql.org; Tue, 01 Aug 2023 15:46:04 +0000 Received: by mail-pl1-x62d.google.com with SMTP id d9443c01a7336-1bbf3da0ea9so24800945ad.2 for ; Tue, 01 Aug 2023 08:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690904758; x=1691509558; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=8s68DTKuLl1hEvm+m5S6j0blihQngrwKxGS73KeOZ90=; b=e/WXZclSQBmE9VGithufixRB8iRourl7XmCS0qAM3qDUUC56JflcpHaml/Tir7bmTf 2m+WEYZJSNKk4M249/VgknYVkVt/hxaVa5X0vwuyxunFwil78dNpj1mM2ayBqYO2qhK1 yk+Yk1ClBtC8f1t5P9t+4rtHaesEwDOVozO9wMwhwxywpNEtVNQS6megRB2edyQetfUB PSFiAV/jq2LsUkKny4MPGSILmk4FDhi2NTJg8cR9gJ1hXwQGZ3WpirsRqU5nww7iIL9q 2PTx1qHRK68kWFKcaXh/E/GnzN5LN4Ppvvu4HGIkcBza5RpXNiFycWmeVtqsx+U9XqNJ bVVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690904758; x=1691509558; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8s68DTKuLl1hEvm+m5S6j0blihQngrwKxGS73KeOZ90=; b=gGkR8Wp+ORypaagt4LUqir9t7qdjiN2+dgWix+aCFLCucYv0vlNXipirKagmHUuPtO CFOUwJN3OUWYTlXk76QPG6xx0eYajFi8SCDZggLtgk8m3Xk8r3wqjt5c0D3Lg8wqsmuy kpDrmhg2goqfxIKOUksyPe1xSYF2DjOyQjNaw0r0b6V1PwcRmJRfoSd5z1sk+NR0v5LW 81yDsTqU3mp1ScXY15tqXB7DywqGI17am1Jl6Z0FcD+6SNiBVHHyL8vABZT5FP8w4Edz xrjhm9bB3HsfYtdHpHwGMHGye65EULdTmZs2K5TDZXgHH/hDgyy5cWC8cRDRZQYiOzQW 0fuw== X-Gm-Message-State: ABy/qLZwAOhQVfrDc/3YklRRa9d+SHqxH/ST8OYJVC8kgbLHD/JpjMM0 pD6CeLXv8+hDPrYD++SjyWQ= X-Google-Smtp-Source: APBJJlHhzITta+Ic12/n+r+z9EEPgfOycfcVKUiFFFaKdODM8rl2WHpSNy0CMjH+8lT29l6rJY5hpA== X-Received: by 2002:a17:902:db06:b0:1b8:8670:541 with SMTP id m6-20020a170902db0600b001b886700541mr11386829plx.25.1690904757643; Tue, 01 Aug 2023 08:45:57 -0700 (PDT) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id 20-20020a170902ee5400b001b9de67285dsm10589214plo.156.2023.08.01.08.45.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Aug 2023 08:45:57 -0700 (PDT) Date: Tue, 1 Aug 2023 08:45:54 -0700 From: Nathan Bossart To: Peter Eisentraut Cc: Bharath Rupireddy , PostgreSQL-development Subject: Re: add timing information to pg_upgrade Message-ID: <20230801154554.GA723589@nathanxps13> References: <20230727235134.GA3658499@nathanxps13> <20230728173814.GA3765390@nathanxps13> <20230728184735.GC3661419@nathanxps13> <20230729211418.GA189222@nathanxps13> <20230731183702.GA537853@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Aug 01, 2023 at 09:46:02AM +0200, Peter Eisentraut wrote: > On 31.07.23 20:37, Nathan Bossart wrote: >> - prep_status("Checking for incompatible \"aclitem\" data type in user tables"); >> + prep_status("Checking for \"aclitem\" data type in user tables"); > > Why these changes? I think this is losing precision about what it's doing. The message is too long, so there's no space between it and the "ok" message: Checking for incompatible "aclitem" data type in user tablesok Instead of altering the messages, we could bump MESSAGE_WIDTH from 60 to 62 or 64. Do you prefer that approach? (BTW this probably needs to be back-patched to v16.) -- Nathan Bossart Amazon Web Services: https://aws.amazon.com