Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wA1qe-001zxx-21 for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Apr 2026 08:31:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wA1qd-00FqU5-0b for pgsql-hackers@arkaria.postgresql.org; Tue, 07 Apr 2026 08:31:47 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wA1qc-00FqTf-2T for pgsql-hackers@lists.postgresql.org; Tue, 07 Apr 2026 08:31:47 +0000 Received: from mail-lj1-x22f.google.com ([2a00:1450:4864:20::22f]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wA1qa-0000000103z-1yYn for pgsql-hackers@postgresql.org; Tue, 07 Apr 2026 08:31:46 +0000 Received: by mail-lj1-x22f.google.com with SMTP id 38308e7fff4ca-38e12c67a6fso5272541fa.1 for ; Tue, 07 Apr 2026 01:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775550703; x=1776155503; darn=postgresql.org; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=0W5zyJLWD7J8bOW4lpslUcnXyxX1+6t19H4UJMobIGo=; b=ceBOWbudwVChwwet+3IytzdRooXpaSUjNuFhHaIw+xvdPbvGutUEaMgaJKOIkskFzE VvPJK+9uvi2atZHISPPGROsV9WOrtwdbGq3Ov2IUwYL2w0WpK/WTrB0TlYTRjrAKDstN 6CzWybtosMMTmB07DXCNkAa5Mx0m8b51WM5paZNFqHwXCyyvAMls8TBwav0qwNCDxNrA dG+kjP9wfxm3q3hpllM+qwvixSMhQ2xeU9L/uEZ9T6XjHIfWPpLAsa7qeD2uivPZKwMA scr4+x6K7xUZZIZ2hNI9sXDvsQk9Se5FeyZM2Wh6tOLgvuVn6BOTjJzGOpy51pwIurZJ Hxyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775550703; x=1776155503; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=0W5zyJLWD7J8bOW4lpslUcnXyxX1+6t19H4UJMobIGo=; b=K7N+E0A3fDMfoKWPBwAxXNvj/v6bPqOjEDFz9DRU7bGE63v9R4WFOGQY7bZtG938+1 GRzoTD4EKUuXT1Pv28HQ1yQ//NhglSRqnaSi36Jj7Y6qSBjtW3dvTqAKwaMRNc74kRP3 N87QemDuxGj8rzJJ2UTYp20X9EhayEK3FTxEqDDO1tdLXpme2q25ofqdJj+feW29IBUS Noa3z1Vtw+24eqtKZqpi6NUKr/AN5lF/d38U6Uw3sq9CUNHeiIW47oTc0g+lyJ6JEcYT jDjDqcP4wj/RRePyrib1jrh/2w39bmbDuR25jf9lCe2JZoL1Zqhdgu5hWJtxxTTeV8Ll PBLQ== X-Gm-Message-State: AOJu0YxXBlG7ZhKZNLlVB59xSHpUwkMzYZbxrNGZsvGxfbIihiFOvWEj 7aFMy0n720thFuMxm4KsBgXm+Lpx2F68OZH5umaTz+P4eb7B8BwmbZFj X-Gm-Gg: AeBDietlY2vw0SppkMe3WN+nnIAHX8vZe23SNVk6AsgB/CqY7nQehnlTVuWK4ZCmn42 n0vQOg8uZXYQbjQSZzHCEnXC+Ad2BNBgmp1crIn5BZrMn+ELyGFXiOqVbi/eQ6hBL7gaM0kQpSe wFW21PIfK4fh7/xP7yapCQFtLFVNTU//E3ooShvNznb631HrtWaM0L1ccFbPQaBQ8+J8NaKclBq XoVmRHGEgmjIpmBaf07zSRFsNA/u89+45MMqrRzpq9fCK+sWMsXMfQ0McrfR8h+T/Wwpx0D7zGc cQxksy1NJk7BQch636D/05em0H0NsY9tsD9nsdf6eSKmEXnHMOjZLem2KhnbNt/buyFtRg4lxR3 z0i1ZQdppL53xkN3yocb6cTmokLxDzfgpatyQV9qqAMqro7YG8hqvmSXwi/BWWGOJw+FCVRHiIm e3hkRrPQtu X-Received: by 2002:a2e:a105:0:b0:38c:13c8:a4b2 with SMTP id 38308e7fff4ca-38d91c196e0mr54662141fa.17.1775550702364; Tue, 07 Apr 2026 01:31:42 -0700 (PDT) Received: from [192.168.1.195] ([176.96.248.240]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-38cd1fa7073sm36331411fa.5.2026.04.07.01.31.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Apr 2026 01:31:41 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------GG0uL0TuRKp8kERjSViJF6jZ" Message-ID: Date: Tue, 7 Apr 2026 15:31:03 +0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Environment variable to disable diffs file output To: Daniel Gustafsson Cc: PostgreSQL Hackers , postgres@jeltef.nl References: Content-Language: ru From: Ilya Cherdakov In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------GG0uL0TuRKp8kERjSViJF6jZ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 06.04.2026 16:47, Jelte Fennema-Nio wrote: > I'm fine with adding the abilitity to configure what pg_regress should > print, but it's unclear to me what's special about the diff output > compared to all the other output? i.e. what is the output you would > actually like to see for your use case? Piping everything to /dev/null > would silence all output except for the exit code, but I guess you > want some output. i.e. what do you do with the output that you get? Do > you only want to know which tests failed? If so, do you care about > which tests are passing? Yes, redirecting all output to /dev/null isn't exactly what I need. Take a specific case, for example: When making numerous changes to tests as part of extensive stability testing (specifically, investigating crashes), the majority of test files may be modified. This results in diffs output for practically every single test, which turns into an unreadable jumble during the test run. In this case, I am not interested in all the diffs the ones associated with a crash. I can inspect those specific cases manually later, without needing the diffs output. Therefore, a flag like `PG_REGRESS_DIFF_OPTS='q'` does not suit my needs. And to find out which tests caused the crash (exit code 1 or 2) I need the entire output. 06.04.2026 21:11, Daniel Gustafsson wrote: > I'm not sure I entirely understand the problem. If you expect lots of > failures, but also don't want to see the test failures, what is the use of > running the tests? Why not run the subset you actually care about and expand > that set as testing fixes bugs/issues? As part of exploratory testing: 1. Output mismatches are considered normal behavior. 2. Exploratory testing almost always affects all tests. Cases where it is necessary to run a small subset of tests are rare. Another case where multiple tests may fail is testing a patch that changes cluster parameters.For example, a patch for the scheduler has been released, and I need to ensure that it doesn't cause crashes when changing the 'random_page_cost' parameter. This parameter significantly changes the plan output, leading to multiple crashes and, consequently, the diffs output. While I'm not interested in the diffs themselves, I do want to know that there haven't been any crashes. In this case, we need to run not just a small group of tests, but everything we have. These are just a couple of examples where disabling diffs output would be useful. --- Also, if the diffs within a single directory run are very large, the output starts to become cluttered with lines like:     #(diff output truncated and silencing output for                             further failing tests...) Which also creates confusion and interferes with output analysis. Example # not ok 1     - test_setup                                133 ms # parallel group (20 tests, in groups of 1):  boolean char name ... # (diff output truncated and silencing output for further failing tests...) not ok 2     + boolean                                    14 ms # (diff output truncated and silencing output for further failing tests...) not ok 3     + char                                        8 ms # (diff output truncated and silencing output for further failing tests...) not ok 4     + name                                        8 ms # (diff output truncated and silencing output for further failing tests...) --- Best regards, Ilya Cherdakov Postgres Professional: https://postgrespro.com --------------GG0uL0TuRKp8kERjSViJF6jZ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit 06.04.2026 16:47, Jelte Fennema-Nio wrote:

> I'm fine with adding the abilitity to configure what pg_regress should
> print, but it's unclear to me what's special about the diff output
> compared to all the other output? i.e. what is the output you would
> actually like to see for your use case? Piping everything to /dev/null
> would silence all output except for the exit code, but I guess you
> want some output. i.e. what do you do with the output that you get? Do
> you only want to know which tests failed? If so, do you care about > which tests are passing?

Yes, redirecting all output to /dev/null isn't exactly what I need.

Take a specific case, for example:
When making numerous changes to tests as part of extensive stability
testing (specifically, investigating crashes), the majority of test
files may be modified. This results in diffs output for practically
every single test, which turns into an unreadable jumble during the
test run. In this case, I am not interested in all the diffs
the ones associated with a crash. I can inspect those specific cases
manually later, without needing the diffs output. Therefore, a flag 
like `PG_REGRESS_DIFF_OPTS='q'` does not suit my needs. And to find 
out which tests caused the crash (exit code 1 or 2) I need the 
entire output.

06.04.2026 21:11, Daniel Gustafsson wrote:
> I'm not sure I entirely understand the problem. If you expect lots of
> failures, but also don't want to see the test failures, what is the use of
> running the tests? Why not run the subset you actually care about and expand
> that set as testing fixes bugs/issues?

As part of exploratory testing:
1. Output mismatches are considered normal behavior.
2. Exploratory testing almost always affects all tests. Cases where
it is necessary to run a small subset of tests are rare.

Another case where multiple tests may fail is testing a patch that 
changes cluster parameters.For example, a patch for the scheduler 
has been released, and I need to ensure that it doesn't cause crashes
when changing the 'random_page_cost' parameter. This parameter 
significantly changes the plan output, leading to multiple crashes and,
consequently, the diffs output. While I'm not interested in the diffs
themselves, I do want to know that there haven't been any crashes.
In this case, we need to run not just a small group of tests,
but everything we have.

These are just a couple of examples where disabling diffs output 
would be useful.

---

Also, if the diffs within a single directory run are very large, 
the output starts to become cluttered with lines like:

    #(diff output truncated and silencing output for 
                            further failing tests...)

Which also creates confusion and interferes with output analysis.
Example

#<long diffs output>
not ok 1     - test_setup                                133 ms
# parallel group (20 tests, in groups of 1):  boolean char name ...
# (diff output truncated and silencing output for further failing tests...)
not ok 2     + boolean                                    14 ms
# (diff output truncated and silencing output for further failing tests...)
not ok 3     + char                                        8 ms
# (diff output truncated and silencing output for further failing tests...)
not ok 4     + name                                        8 ms
# (diff output truncated and silencing output for further failing tests...)
<etc.>

---
Best regards,
Ilya Cherdakov
Postgres Professional: https://postgrespro.com
--------------GG0uL0TuRKp8kERjSViJF6jZ--