Re: add timing information to pg_upgrade - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: add timing information to pg_upgrade
Date
Msg-id 20230731183702.GA537853@nathanxps13
Whole thread Raw
In response to Re: add timing information to pg_upgrade  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: add timing information to pg_upgrade
List 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

pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: should frontend tools use syncfs() ?
Next
From: Nathan Bossart
Date:
Subject: Re: should frontend tools use syncfs() ?