Re: add timing information to pg_upgrade
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Peter Eisentraut <peter@eisentraut.org>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2023-08-02T17:39:39Z
Lists: pgsql-hackers
Attachments
- 0001-work-in-progress-fix-pg_upgrade-output.patch (text/x-diff)
On Wed, Aug 02, 2023 at 09:09:14AM -0700, Nathan Bossart wrote: > On Wed, Aug 02, 2023 at 01:02:53PM +0530, Bharath Rupireddy wrote: >> On Wed, Aug 2, 2023 at 12:45 PM Peter Eisentraut <peter@eisentraut.org> 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. Here is a work-in-progress patch that seems to get things pretty close to what Peter is suggesting. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
Commits
-
pg_upgrade: Bump MESSAGE_WIDTH.
- 2e7d15ab69d9 16.0 landed
- 9625845532ae 17.0 landed