Re: pg_regress: Treat child process failure as test failure

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_regress: Treat child process failure as test failure
Date: 2023-02-23 08:53:57
Message-ID: D21A9CA0-2644-4C01-AE4C-F07DD6C841CE@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 22 Feb 2023, at 21:55, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>>> On 22 Feb 2023, at 21:33, Andres Freund <andres(at)anarazel(dot)de> wrote:
>>> On 2023-02-22 15:10:11 +0100, Daniel Gustafsson wrote:
>>>> Rebased patch to handle breakage of v2 due to bd8d453e9b.
>
>>> I think we probably should just apply this? The current behaviour doesn't seem
>>> right, and I don't see a downside of the new behaviour?
>
>> Agreed, I can't think of a regression test where we wouldn't want this. My
>> only concern was if any of the ECPG tests were doing something odd that would
>> break from this but I can't see anything.
>
> +1. I was a bit surprised to realize that we might not count such
> a case as a failure.

Done that way, thanks!

--
Daniel Gustafsson

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message shiy.fnst@fujitsu.com 2023-02-23 08:55:27 RE: Time delayed LR (WAS Re: logical replication restrictions)
Previous Message David Geier 2023-02-23 08:48:35 Re: pg_stat_statements and "IN" conditions