Re: Add -k/--link option to pg_combinebackup

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Israel Barth Rubio <barthisrael(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add -k/--link option to pg_combinebackup
Date: 2025-03-18 18:49:05
Message-ID: CA+TgmoY74HveJqvDCOSVJ1nm7EKmQOaAKoHFnMAxykD-j5cqbw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 18, 2025 at 1:55 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 10s added to every check-world run doesn't sound "cheap" to me.

Really? If you're sensitive to the time the tests take to run, maybe
use 'meson test' rather than 'make check-world'? I do that locally
with MESON_TESTTHREADS=8 and the entire test suite finishes in under 3
minutes. A 10-second pgindent test will add something to that,
presumably, because it'll take up one of those test threads for the
time it's running, but if you assume perfect thread utilization before
and after adding this test we're talking about the difference between
'meson test' finishing in 2:55 and 2:57, or something like that. That
seems like pretty cheap insurance to me for what is, at least for me,
a common error.

(make check-world for me takes 12:57 -- and yes that could be faster
with parallelism too, but then the output is jumbled. At any rate, if
I'm waiting that long, I'm getting up and walking away from the
computer and then the difference between being gone for 13 minutes and
13 minutes and 10 seconds isn't really material either, at least not
to me.)

> However, both pg_bsd_indent and the typedefs list are in-tree
> nowadays, so I don't see any reason that this couldn't be a
> totally self-contained check.

Well, +1 from me. Every year when I go through the commit log from the
previous year for contribution statistics, it always shocks me how
fix-up commits we have. Now, some of that is unavoidable -- people are
always going to miss things in review and discover them after commit.
But it should be possible to reduce purely mechanical errors like
failing to rerun pgindent after the very last cosmetic change, or
whatever. I'd like to spend more time on substantive issues and less
on things that could have been caught automatically. Tons and tons of
commits have two, three, or even more fix-up commits and that all adds
up to a lot of committer time that could be better spent.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sami Imseih 2025-03-18 18:54:18 Re: pg_stat_statements and "IN" conditions
Previous Message Robert Haas 2025-03-18 18:46:16 Re: making EXPLAIN extensible