Re: Reducing logs produced by TAP tests running pg_regress on crash - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Reducing logs produced by TAP tests running pg_regress on crash
Date
Msg-id CA+hUKGKoFomAqS8myseS6Yc8D_D2HREp5Gz246pycz690WvfUQ@mail.gmail.com
Whole thread Raw
In response to Re: Reducing logs produced by TAP tests running pg_regress on crash  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Reducing logs produced by TAP tests running pg_regress on crash
List pgsql-hackers
On Fri, Jul 22, 2022 at 1:09 PM Michael Paquier <michael@paquier.xyz> wrote:
> On Thu, Jun 23, 2022 at 02:30:13PM +0900, Michael Paquier wrote:
> > One idea I got to limit the useless output generated is to check the
> > status of the cluster after running the regression test suite as
> > restart_on_crash is disabled by default in Cluster.pm, and avoid any
> > follow-up logic in these tests if the cluster is not running anymore,
> > as of the attached.
>
> So, this is still an open item..
>
> Thomas, any objections about this one?  Checking for the status of the
> node after completing pg_regress still sounds like a good idea to me,
> because as restart_after_crash is disabled we would generate a ton of
> logs coming from regression.diffs for nothing.  On top of that the
> parallel connections make harder finding which query failed, and the
> logs of the backend provide enough context already on a hard crash.

What if the clue we need to understand why it crashed was in the
regression diffs that we didn't dump?

I wonder if we should move the noise suppression check closer to
pg_regress, so that it works also for the "main" pg_regress run, not
only the one in this new TAP test.  As discussed in this thread,
inconclusively:

https://www.postgresql.org/message-id/flat/CA%2BhUKGL7hxqbadkto7e1FCOLQhuHg%3DwVn_PDZd6fDMbQrrZisA%40mail.gmail.com



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Reducing logs produced by TAP tests running pg_regress on crash
Next
From: Thomas Munro
Date:
Subject: Re: Windows now has fdatasync()