Re: Still another race condition in recovery TAP tests

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Still another race condition in recovery TAP tests
Date: 2017-09-09 09:39:50
Message-ID: CAB7nPqQ9k0joMQBtbcG6ybWiL+AkhOQKkwkYyQP-ReM8PiZtcw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Sep 9, 2017 at 1:43 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>>> 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.

Definitely...

> 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.

Actually, looking at the CPAN file of the module here:
http://cpansearch.perl.org/src/DMUEY/File-Copy-Recursive-0.38/Recursive.pm
There is no minimum version defined. There is even some handling for
perl 5.6 so I think that we should actually be fine from a
compatibility point of view. Also dircopy() uses fcopy(), which just
uses File::Copy::copy() to copy a file. A difference wiht
RecursiveCopy is that File::Copy::Recursive does not fail if copy()
itself fails (see "copy(@_) or return;" in "sub fcopy"). It just
returns for a failure.

We have actually discussed about RecursiveCopy and
File::Copy::Recursive two years ago:
https://www.postgresql.org/message-id/20151123212707.GD4073@alvherre.pgsql
The first version of RecursiveCopy did not need any fancy copy except
a simple recursive function, and I personally still like the fact that
symlinks are not handled. Should we care about that actually for cases
where we take a FS-backup with tablespaces and a pg_wal symlink? Such
case has not showed up yet, but if it does I think that we could
consider integrating File::Copy::Recursive.

In short, I'd still like to keep RecursiveCopy for now, but change its
code so as a copy() is not a hard failure. What do you think?
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Adrien Nayrat 2017-09-09 10:39:43 Re: PG 10 release notes
Previous Message Fabien COELHO 2017-09-09 09:02:03 Re: pgbench more operators & functions