Michael Paquier <michael.paquier@gmail.com> writes:
> On Sat, Sep 9, 2017 at 11:32 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> In a moment of idleness I tried to run the TAP tests on pademelon,
>> which is a mighty old and slow machine.
> How long did it take?
The last time I tried it, make check-world took about 3 hours IIRC.
But that was a few months ago, I suspect it's more now. I re-launched
the run after diagnosing this failure; it's gotten past the recovery
tests (proving that this is a race condition not a hard failure) and
is somewhere in the contrib tests, about 2 hours in.
>> I'm not real sure if the appropriate answer to this is "we need to fix
>> RecursiveCopy" or "we need to fix the callers to not call RecursiveCopy
>> until the source directory is stable". Thoughts?
> ... So making RecursiveCopy really looks
> like the best bet in the long term.
Yeah, even if we fixed this particular call site, I'm sure the issue
would come up again. Certainly we expect hot backups to work with
a changing source directory.
>> (I do kinda wonder why we rolled our own RecursiveCopy; surely there's
>> a better implementation in CPAN?)
> This comes from here, which is something I got involved in:
> So the idea here is really to have:
> 1) Something compatible down to perl 5.8.
> 2) Something which is not external, which is where we could have used
> File::Copy::Recursive (only compatible from 5.12 if I recall
> correctly? I am too lazy to check now).
Hm. Even if we don't want to use File::Copy::Recursive, maybe we should
look at it and see what (if anything) it does about source-tree changes.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
