Re: IPC::Run::time[r|out] vs our TAP tests - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: IPC::Run::time[r|out] vs our TAP tests
Date
Msg-id 8B5D6EE7-E4A9-4AA2-AF33-2C7BB075CB05@yesql.se
Whole thread Raw
In response to Re: IPC::Run::time[r|out] vs our TAP tests  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> On 11 Feb 2026, at 21:19, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Daniel Gustafsson <daniel@yesql.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




pgsql-hackers by date:

Previous
From: "Matheus Alcantara"
Date:
Subject: Re: Add CREATE SCHEMA ... LIKE support
Next
From: "David G. Johnston"
Date:
Subject: Re: Add CREATE SCHEMA ... LIKE support