Re: backup manifests and contemporaneous buildfarm failures - Mailing list pgsql-hackers

From Robert Haas
Subject Re: backup manifests and contemporaneous buildfarm failures
Date
Msg-id CA+Tgmob2fnWpeg5ok2Odq9H33e6T9AKa4SJ9aKbGvRGgT=NyLA@mail.gmail.com
Whole thread Raw
In response to Re: backup manifests and contemporaneous buildfarm failures  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: backup manifests and contemporaneous buildfarm failures  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Apr 3, 2020 at 6:48 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I'm guessing that we're looking at a platform-specific difference in
> whether "rm -rf" fails outright on an unreadable subdirectory, or
> just tries to carry on by unlinking it anyway.

My intention was that it would be cleaned by the TAP framework itself,
since the temporary directories it creates are marked for cleanup. But
it may be that there's a platform dependency in the behavior of Perl's
File::Path::rmtree, too.

> A partial fix would be to have the test script put back normal
> permissions on that directory before it exits ... but any failure
> partway through the script would leave a time bomb requiring manual
> cleanup.

Yeah. I've pushed that fix for now, but as you say, it may not survive
contact with the enemy. That's kind of disappointing, because I put a
lot of work into trying to make the tests cover every line of code
that they possibly could, and there's no reason to suppose that
pg_validatebackup is the only tool that could benefit from having code
coverage of those kinds of scenarios. It's probably not even the tool
that is most in need of such testing; it must be far worse if, say,
pg_rewind can't cope with it.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Nikita Glukhov
Date:
Subject: Re: Ltree syntax improvement
Next
From: Robert Haas
Date:
Subject: Re: backup manifests and contemporaneous buildfarm failures