On 3/3/21 12:47 AM, Andres Freund wrote:
> Hi,
>
> On 2021-03-02 21:20:52 -0500, Andrew Dunstan wrote:
>> On 3/2/21 8:27 PM, Michael Paquier wrote:
>>> On Tue, Mar 02, 2021 at 04:54:57PM -0800, Andres Freund wrote:
>>>> It still does, even after
>>>>
>>>> commit 1e6e40447115ca7b4749d7d117b81b016ee5e2c2 (upstream/master, master)
>>>> Author: Andres Freund <and...@anarazel.de>
>>>> Date: 2021-03-01 09:52:15 -0800
>>>>
>>>> Fix recovery test hang in 021_row_visibility.pl on windows.
>>>>
>>>> ? I didn't see failures after that?
>>> Yes. Testing this morning on top of 5b2f2af, it fails for me with a
>>> "Terminating on signal SIGBREAK".
>>>
>> Yes, I saw similar this morning, which woud have been after that commit.
> I can't reproduce that here - could either (or both) of you send
>
> src/test/recovery/tmp_check/log/regress_log_021_row_visibility
> src/test/recovery/tmp_check/log/021_row_visibility_standby.log
> src/test/recovery/tmp_check/log/021_row_visibility_primary.log
>
> of a failed run? And maybe how you're invoking it?
>
> Does adding a
>
> $psql_primary{run}->finish;
> $psql_standby{run}->finish;
> before
> $psql_primary{run}->kill_kill;
> $psql_standby{run}->kill_kill;
>
> fix the issue?
>
I will check later on. Note that IPC::Run's kill_kill is known to cause
problems on MSWin32 perl, see the other recovery checks where we skip
tests involving it - crash_recovery and logical_decoding.
Maybe we need a wrapper for it that dies if called on MSWin32 perl. That
at least would not crash the invoking service with a nasty signal, and
the buildfarm would actually tell us about the issue.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
