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

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: IPC::Run::time[r|out] vs our TAP tests
Date: 2024-10-31 12:27:39
Message-ID: D94A354B-00F2-4378-951A-24D3557C6A79@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 28 Oct 2024, at 11:56, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>
> On 09/04/2024 20:10, Daniel Gustafsson wrote:
>> Turning the timeout into a timer and returning undef along with logging a test
>> failure in case of expiration seems a bit saner (maybe Andrew can suggest an
>> API which has a better Perl feel to it). Most callsites don't need any changes
>> to accommodate for this, the attached 0002 implements this timer change and
>> modify the few sites that need it, converting one to plain query() where the
>> added complexity of query_until isn't required.
>
> +1. The patch looks good to me. I didn't comb through the tests to check for bugs of omission, i.e. cases where the caller would need adjustments because of this, I trust that you found them all.

Thanks for review!

>> =item $session->quit
>> Close the session and clean up resources. Each test run must be closed with
>> C<quit>. Returns TRUE when the session was cleanly terminated, otherwise
>> FALSE. A testfailure will be issued in case the session failed to finish.
>
> What does "session failed to finish" mean? Does it mean the same as "not cleanly terminated", i.e. a test failure is issued whenever this returns FALSE?

It was very literally referring to the finish() method. I've reworded the
comment to indicated that it throws a failure in case the process returns a
non-zero exit status to finish().

> typo: testfailure -> test failure

Fixed.

>> my $pid = $bgpsql->query('SELECT pg_backend_pid()');
>> +isnt($pid, undef, 'Get backend PID');
>> # create the database, prevent drop database via lock held by a 2PC transaction
>> ok( $bgpsql->query_safe(
>
> I'm not sure I understand these changes. These can only fail if the query() or query_until() function times out, right? In that case, the query() or query_until() would also report a test failure, so these additional checks after the call seem redundant. They don't do any harm either, but I wonder why have them in these particular call sites and not in other query() or query_until() calls.

Fair point, they were added to provide additional detail in case of failure,
but they are to some degree overzealous and definitely not required.

Attached is a v2 with the above changes and 0003 dropped due to already being
implemented.

--
Daniel Gustafsson

Attachment Content-Type Size
v2-0001-Configure-interactive-instance-to-restart-timer.patch application/octet-stream 1.7 KB
v2-0002-Report-test-failure-rather-than-aborting-in-case-.patch application/octet-stream 4.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jesper Pedersen 2024-10-31 12:59:01 Re: protocol-level wait-for-LSN
Previous Message jian he 2024-10-31 12:15:58 Re: Eager aggregation, take 3