Re: Still another race condition in recovery TAP tests
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2017-09-11T14:55:12Z
Lists: pgsql-hackers
Attachments
- tap-copypath-enoent-2.patch (text/x-diff) patch
Michael Paquier <michael.paquier@gmail.com> writes: > On Sun, Sep 10, 2017 at 12:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> The specific case we need to allow is "ENOENT on a file/dir that was >> there a moment ago". I think it still behooves us to complain about >> anything else. If you think it's a simple fix, have at it. But >> I see at least three ways for _copypath_recurse to fail depending on >> exactly when the file disappears. > With the check for -d and -f, this brings indeed the count to three > code paths. With the patch attached, I have added some manual sleep > calls in RecursiveCopy.pm and triggered manual deletions of the source > repository. The copy is able to complete in any case, warning about > missing directories or files. I have added warn messages in the patch > when ENOENT is triggered, though I think that those should be removed > in the final patch. Hm, I don't much like having it silently ignore files that are present; that seems like a foot-gun in the long run. What do you think of the attached? > By the way, 010_logical_decoding_timelines.pl does not need to include > RecursiveCopy. Good catch. regards, tom lane
Commits
-
Fix RecursiveCopy.pm to cope with disappearing files.
- e183530550dc 11.0 landed
- bd18960cb93f 10.0 landed
- 64e2b29bdea0 9.6.6 landed
-
Refactor Perl test code
- 1caef31d9e55 9.6.0 cited