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 1qREPf-000zAL-MR for pgsql-hackers@arkaria.postgresql.org; Wed, 02 Aug 2023 16:09:27 +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 1qREPd-006Fy1-HY for pgsql-hackers@arkaria.postgresql.org; Wed, 02 Aug 2023 16:09:25 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qREPd-006Fxt-8f for pgsql-hackers@lists.postgresql.org; Wed, 02 Aug 2023 16:09:25 +0000 Received: from mail-pf1-x430.google.com ([2607:f8b0:4864:20::430]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qREPY-000Af6-P7 for pgsql-hackers@postgresql.org; Wed, 02 Aug 2023 16:09:25 +0000 Received: by mail-pf1-x430.google.com with SMTP id d2e1a72fcca58-686daaa5f1fso5011026b3a.3 for ; Wed, 02 Aug 2023 09:09:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690992558; x=1691597358; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=gLBgUQWIqycWVKVcspXKMn9qlB/tIRMLXlPCxq3zyKM=; b=qUdmn0LwNM2j+5OYjFem473HpSvt5/GVgcKFOSpIoo7IZ1XDVOB/vlN3r9TkDpDyyQ hQaIQLrTXOVwXBXvBVA77hbc4pTa6d9C8S9u/0tjGxIJyz+GP0RlqWBeF/jxEpDv7YmY HcUji7ssNOAoNHY8fY9mGg5UoeJAXEzoPSEq+qyoWPL7gH34KrapY1p+8toj00A1r8lV I1oVx/8D9LWGXVc0ldy8G1oRI48LKwGglnUf7h6QpcM9gZDrYE4h43ggTvd85CtncP4I NbjOrWtMkLQZHiEUvOYvkR48G8S5evxC5nooEIMcY82ItcjvHWBOj7wFgJ/ACrNEnIDP R3+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690992558; x=1691597358; h=in-reply-to:content-transfer-encoding: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=gLBgUQWIqycWVKVcspXKMn9qlB/tIRMLXlPCxq3zyKM=; b=L/xP0+bq83khKUq2X5WwBn8f0phCzkThOhAlUOH6MLnKIK9M47mr2DKxuR/HtNf8ec BcXDd6d4Wz/FslkCCna1af36gg/+13pc4oqv3jaDUMdty34rryTXuRPFRjluKn/Z3QaK TjUstElzZuKCdUo0LBDIbd9uhtPkupypIexy7wKrM9wM9zQyHHcDU225Mb2rADUL3k93 NSv7dt147VJiGTIM/E0U7CL+RMyqQc0VRvCusv1TI7RSS4K7G+4k+k5zbCIiTiWMsx3p WGyYd6EScn4JtviVux1aVU8UacKtgbSsBZ4/9mKpMuhHvrUgac73VdwO6uz+R6u9dAwR Ts6w== X-Gm-Message-State: ABy/qLa/SB1lovB9Z1eD8cztXcN4MIA2uW2eMZDaBbWnQWjqnyPTGlqa XvN9OhdrwDRQYk8ocBWC63x1Iww5GaY= X-Google-Smtp-Source: APBJJlHZDEMvGwSjT0+Lhn4GCet9ciYF8VKTnSMwPRaK6z1N/afOGEDxQbaJjxTguOFKBJKPJYuN4w== X-Received: by 2002:a05:6a00:13a5:b0:682:4801:93d3 with SMTP id t37-20020a056a0013a500b00682480193d3mr18946984pfg.31.1690992558192; Wed, 02 Aug 2023 09:09:18 -0700 (PDT) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id fk25-20020a056a003a9900b00682a8e600f0sm11304022pfb.35.2023.08.02.09.09.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Aug 2023 09:09:17 -0700 (PDT) Date: Wed, 2 Aug 2023 09:09:14 -0700 From: Nathan Bossart To: Bharath Rupireddy Cc: Peter Eisentraut , PostgreSQL-development Subject: Re: add timing information to pg_upgrade Message-ID: <20230802160914.GA1025261@nathanxps13> References: <20230728173814.GA3765390@nathanxps13> <20230728184735.GC3661419@nathanxps13> <20230729211418.GA189222@nathanxps13> <20230731183702.GA537853@nathanxps13> <20230801154554.GA723589@nathanxps13> <68c0092c-2d81-68a4-04c5-920bc428feac@eisentraut.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Aug 02, 2023 at 01:02:53PM +0530, Bharath Rupireddy wrote: > On Wed, Aug 2, 2023 at 12:45 PM Peter Eisentraut wrote: >> I think we should change the output format to be more like initdb, like >> >> Doing something ... ok >> >> without horizontally aligning all the "ok"s. > > While this looks simple, we might end up with a lot of diff and > changes after removing MESSAGE_WIDTH. There's a significant part of > pg_upgrade code that deals with MESSAGE_WIDTH. I don't think it's > worth the effort. Therefore, I'd prefer the simplest possible fix - > change the message to '"Checking for \"aclitem\" data type in user > tables". It may be an overkill, but we can consider adding > Assert(sizeof(message) < MESSAGE_WIDTH) in progress report functions > to not encourage new messages to end up in the same formatting issue. I don't think it's that difficult. ІMO the bigger question is whether we want to back-patch such a change to v16 at this point. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com