Report runtimes in pg_upgrade verbose mode
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t49818psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 04:31 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t49818_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t49818_1 && git checkout t49818_1Patchset v1 (message #1) is on t49818_1
When doing performance hacking on pg_upgrade it's often important to see
individual runtimes to isolate changes. I've written versions of the attached
patch numerous times, and I wouldn't be surprised if others have done the same.
Is there any interest in adding something like the attached to pg_upgrade? The
patch needs some cleaning and tidying up but I wanted to to gauge interest
before investing time. I've added it to verbose mode mainly since it's not
really all that informative for regular users I think.
--
Daniel Gustafsson
On Wed, Jun 19, 2024 at 04:50:59PM +0200, Daniel Gustafsson wrote:
When doing performance hacking on pg_upgrade it's often important to see
individual runtimes to isolate changes. I've written versions of the attached
patch numerous times, and I wouldn't be surprised if others have done the same.
Indeed: /messages/by-id/flat/20230727235134.GA3658499@nathanxps13
Is there any interest in adding something like the attached to pg_upgrade? The
patch needs some cleaning and tidying up but I wanted to to gauge interest
before investing time. I've added it to verbose mode mainly since it's not
really all that informative for regular users I think.
I've been using 'ts -i' as Peter suggested [0]/messages/by-id/32d24bcf-9ac4-b10e-4aa2-da6975312eb2@eisentraut.org, and that has worked
decently well. One other thing that I've noticed is that some potentially
long-running tasks don't have corresponding reports. For example, the
initial get_db_rel_and_slot_infos() on the old cluster doesn't report
anything, but that is often one of the most time-consuming steps.
[0]: /messages/by-id/32d24bcf-9ac4-b10e-4aa2-da6975312eb2@eisentraut.org
--
nathan