Re: Minor improvements to test log navigability

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Minor improvements to test log navigability
Date: 2022-05-17 01:56:09
Message-ID: CA+hUKGLJ-YD-D8=2ZVMhG7vz7QY0iVynWa_mWUOEiPPR6_SdXg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 17, 2022 at 4:18 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> > On 2022-May-16, Thomas Munro wrote:
> >> 1. It seems a bit useless to have a load of "FATAL: the database
> >> system is in recovery mode" spam whenever the server crashes under
> >> src/test/regress. Any reason not to just turn that off, as we do for
> >> the TAP tests?
>
> > I don't know of any. Let's.
>
> Have you actually tested what happens? I fear this would just
> result in different spam.

I'd forgotten that we already do this on CI, via
src/tools/ci/pg_ci_base.conf, so we can compare. A CI postmaster.log
that ends with "shutting down because restart_after_crash is off":

https://api.cirrus-ci.com/v1/artifact/task/6537277877780480/log/src/test/regress/log/postmaster.log

The build farm version has ~350 lines of "FATAL: the database system
is in recovery mode" instead:

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=seawasp&dt=2022-05-16%2023%3A17%3A49

Admittedly that is nothing compared to the huge amount of extra log
spam caused by regression.diffs filling up with these:

- ...the complete expected output of each test spanning many lines...
- ...
- ...
+psql: error: connection to server on socket
"/tmp/pg_regress-ZqXocK/.s.PGSQL.5678" failed: FATAL: the database
system is in recovery mode

In the CI version, that looks like:

- ...the complete expected output of each test spanning many lines...
- ...
- ...
+psql: error: connection to server on socket
"/tmp/pg_regress-T35Yzi/.s.PGSQL.51696" failed: No such file or
directory
+ Is the server running locally and accepting connections on that socket?

I wonder if there would be a good way to filter those "never managed
to connect" cases out... Exit code 2 (EXIT_BADCONN) is not the
answer, because you get that also for servers that go away due to a
crash where you do want to be able to see the diff, for information
about where it crashed.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andy Fan 2022-05-17 02:00:35 Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not?
Previous Message Michael Paquier 2022-05-17 00:05:44 Re: Minor improvements to test log navigability