Re: IPC::Run::time[r|out] vs our TAP tests

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: IPC::Run::time[r|out] vs our TAP tests
Date: 2026-02-11 20:39:20
Message-ID: 8B5D6EE7-E4A9-4AA2-AF33-2C7BB075CB05@yesql.se
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 11 Feb 2026, at 21:19, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>> [ v4 patches for better timeout handling ]
>
> I got around to reviewing these finally. v4-0001 looks good, except
> that there is now another copy of the same logic in 030_pager.pl
> which should be fixed in the same way. Proposed revision to do that
> attached.

LGTM.

> I'm not very comfortable with v4-0002, specifically the decision
> that sub query and sub query_until should now return undef instead
> of dying. I think that next to no call sites will handle that well.
> Also, as this stands both subs will fail to reset $self->{stdout},
> pretty much guaranteeing that the next query will fail too.
> (Although if psql is stuck, do we have any chance at all of
> subsequent tests succeeding? Dying might be superior to spewing
> a bunch of content-free follow-on failures.)

IIRC the rationale was (but it's been a while so..) to catch queries which had
incorrect end criteria and report as error instead, but that will perhaps
mostly be found during hacking and dying isn't really a problem there.

> a1d7ae2b2 already made what I think is the critical debuggability
> improvement in sub query, namely to not die until after reporting
> whatever we got from the query. I'm inclined to suggest that
> sub query_until should be made to print a similar report, but
> still die on timeout.

Agreed, that's a solid improvement.

--
Daniel Gustafsson

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2026-02-11 20:51:57 Re: Add CREATE SCHEMA ... LIKE support
Previous Message Matheus Alcantara 2026-02-11 20:24:48 Re: Add CREATE SCHEMA ... LIKE support