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

From Heikki Linnakangas
Subject Re: IPC::Run::time[r|out] vs our TAP tests
Date
Msg-id e7c4c0af-39e1-432e-a67c-7c7a96fc4151@iki.fi
Whole thread Raw
In response to Re: IPC::Run::time[r|out] vs our TAP tests  (Daniel Gustafsson <daniel@yesql.se>)
List pgsql-hackers
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.

> =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?

typo: testfailure -> test failure


> diff --git a/src/test/recovery/t/031_recovery_conflict.pl b/src/test/recovery/t/031_recovery_conflict.pl
> index d87efa823fd..62936f52d20 100644
> --- a/src/test/recovery/t/031_recovery_conflict.pl
> +++ b/src/test/recovery/t/031_recovery_conflict.pl
> @@ -253,9 +253,7 @@ $res = $psql_standby->query_until(
>      -- wait for lock held by prepared transaction
>         SELECT * FROM $table2;
>      ]);
> -ok(1,
> -       "$sect: cursor holding conflicting pin, also waiting for lock, established"
> -);
> +isnt($res, undef, "$sect: cursor holding conflicting pin, also waiting for lock, established");
>  
>  # just to make sure we're waiting for lock already
>  ok( $node_standby->poll_query_until(
> diff --git a/src/test/recovery/t/037_invalid_database.pl b/src/test/recovery/t/037_invalid_database.pl
> index 6d1c7117964..c8c20077f85 100644
> --- a/src/test/recovery/t/037_invalid_database.pl
> +++ b/src/test/recovery/t/037_invalid_database.pl
> @@ -94,6 +94,7 @@ is($node->psql('postgres', 'DROP DATABASE regression_invalid'),
>  my $cancel = $node->background_psql('postgres', on_error_stop => 1);
>  my $bgpsql = $node->background_psql('postgres', on_error_stop => 0);
>  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.

> The tab completion test can use the API call for automatically restart the
> timer to reduce the complexity of check_completion a hair.  Done in 0001 (but
> really not necessary).

+1

> Commit Af279ddd1c2 added this sequence to 040_standby_failover_slots_sync.pl in
> the recovery tests:
> 
>     $back_q->query_until(
>         qr/logical_slot_get_changes/, q(
>        \echo logical_slot_get_changes
>        SELECT pg_logical_slot_get_changes('test_slot', NULL, NULL);
>     ));
> 
>     ... <other tests> ...
> 
>     # Since there are no slots in standby_slot_names, the function
>     # pg_logical_slot_get_changes should now return, and the session can be
>     # stopped.
>     $back_q->quit;
> 
> There is no guarantee that pg_logical_slot_get_changes has returned when
> reaching this point.  This might still work as intended, but the comment is
> slightly misleading IMO.

Agreed, it would be good to actually check that it returns.

> recovery/t/043_wal_replay_wait.pl calls pg_wal_replay_wait() since 06c418e163e
> in a background session which it then skips terminating.  Calling ->quit is
> mandated by the API, in turn required by IPC::Run.  Calling ->quit on the
> process makes the test fail from the process having already exited, but we can
> call ->finish directly like we do in test_misc/t/005_timeouts.pl.  0003 fixes
> this.

Alexander included this fix in commit 3c5db1d6b016 already.

-- 
Heikki Linnakangas
Neon (https://neon.tech)




pgsql-hackers by date:

Previous
From: Alena Rybakina
Date:
Subject: Re: Consider the number of columns in the sort cost model
Next
From: Umar Hayat
Date:
Subject: Re: ActiveState Perl is not valid anymore to build PG17 on the Windows 10/11 platforms, So Documentation still suggesting it should be updated