Re: WIP patch for avoiding duplicate initdb runs during "make check"

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP patch for avoiding duplicate initdb runs during "make check"
Date: 2017-07-03 22:30:33
Message-ID: CAB7nPqS9-byBtsRWK_5Tb28a3UCYPxXJ0ZEykKKGo5QpnBSLMQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 3, 2017 at 11:00 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>> On Mon, Jul 3, 2017 at 9:25 PM, Greg Stark <stark(at)mit(dot)edu> wrote:
>>> On 2 July 2017 at 18:33, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> system("cp -a ...") call in favor of something more portable.
>
>>> If we're ok with using Perl there's File::Copy::Recursive::dircopy()
>>> which does exactly that.
>
>> This stuff needs to support perl down to 5.8.0, and that's a reason
>> behind having src/test/perl/RecursiveCopy.pm. So I would suggest just
>> to use that. cp is not portable on Windows as well, that's a recipe
>> for non-portable code there.

This was under the assumption of "if we use perl" :)

> I can't see going this path in pg_regress, because then you would have
> exactly zero test functionality in a non-Perl build.

Indeed, release tarballs don't need perl to work. So that's a no-go.

> What I had in
> mind was a frontend-friendly version of backend/storage/file/copydir.c,
> either just dropped into pg_regress.c or put in src/common/.

+1 for src/common/.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-07-03 22:42:52 Re: Error while copying a large file in pg_rewind
Previous Message Alvaro Herrera 2017-07-03 20:34:29 Re: GSoC 2017: Foreign Key Arrays