On Tue, May 17, 2022 at 4:18 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Alvaro Herrera <alvhe...@alvh.no-ip.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.
