Re: buildfarm windows checks / tap tests on windows

Hi,

On 2021-03-02 21:20:11 -0800, Andres Freund wrote:
> On 2021-03-02 12:57:57 -0800, Andres Freund wrote:
> > t/003_recovery_targets.pl ............ 7/9
> > # Failed test 'multiple conflicting settings'
> > # at t/003_recovery_targets.pl line 151.
> >
> > # Failed test 'recovery end before target reached is a fatal error'
> > # at t/003_recovery_targets.pl line 177.
> > t/003_recovery_targets.pl ............ 9/9 # Looks like you failed 2 tests of 9.
> > t/003_recovery_targets.pl ............ Dubious, test returned 2 (wstat 512, 0x200)
> > Failed 2/9 subtests
>
> This appears to be caused by stderr in windows docker containers to
> somehow not work quite right. cirrus-ci uses docker on windows.
>
> If you look e.g. at https://cirrus-ci.com/task/6111560255930368, and
> specifically at the relevant log file:
> https://api.cirrus-ci.com/v1/artifact/task/6111560255930368/log/src/test/recovery/tmp_check/log/003_recovery_targets_primary.log
> you can see that it's, uh, less full than we normally expect:
> 1 file(s) copied.
> 1 file(s) copied.
> 1 file(s) copied.
> 1 file(s) copied.
>
> As that test uses the log file to determine the state of servers:
> > my $logfile = slurp_file($node_standby->logfile());
> > ok($logfile =~ qr/multiple recovery targets specified/,
> > 'multiple conflicting settings');
>
> that doesn't work.
>
>
> I was *very* confused by this for a while. But finally the cluebait hit
> when I discovered that stderr works just fine for *other*
> programs. Including the programs that evidently log into
> 003_recovery_targets_primary.log. The problem is that
> pgwin32_is_service() somehow decides that postgres is running as a
> service. Despite that not really being the case (I guess somehow
> internally docker containers are started below a service, and that
> causes the problem).
>
> I hate everything right now. So much.
>
> I think it's quite nasty that postgres just silently starts to log to
> the event log. Why on earth wasn't the solution instead to hardcode that
> as a server parameter in pg_ctl register?
>
> Not sure what a good fix is for this.

FWIW, just forcing pgwin32_is_service() to return false seems to get the
cirrus tests past 003_recovery_targets.pl. Possible it'll not finish due
to other problems (or too tight timeouts I set), but at least this one
can be considered diagnosed I think.

https://cirrus-ci.com/task/5049764917018624?command=windows_worker_buf#L132

Greetings,

Andres Freund