Re: add timing information to pg_upgrade

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: add timing information to pg_upgrade
Date: 2023-07-31 18:37:02
Message-ID: 20230731183702.GA537853@nathanxps13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 31, 2023 at 11:34:57AM +0530, Bharath Rupireddy wrote:
> Either of "Checking for \"aclitem\" data type usage" or "Checking for
> \"aclitem\" data type in user tables" seems okay to me, however, I
> prefer the second wording.

Okay. I used the second wording for all the data type checks in v3. I
also marked the timing strings for translation. I considered trying to
extract psql's PrintTiming() so that it could be reused in other utilities,
but the small differences would likely make translation difficult, and the
logic isn't terribly long or sophisticated.

My only remaining concern is that this timing information could cause
pg_upgrade's output to exceed 80 characters per line. I don't know if this
is something that folks are very worried about in 2023, but it still seemed
worth bringing up.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Attachment Content-Type Size
v3-0001-harmonize-data-type-status-messages-in-pg_upgrade.patch text/x-diff 2.3 KB
v3-0002-add-timing-information-to-pg_upgrade.patch text/x-diff 2.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2023-07-31 18:39:46 Re: should frontend tools use syncfs() ?
Previous Message Nathan Bossart 2023-07-31 17:51:38 Re: should frontend tools use syncfs() ?