On Tue, Oct 17, 2017 at 5:01 AM, Robert Haas wrote:
> On Fri, Oct 6, 2017 at 5:57 AM, Craig Ringer wrote:
>>> Fewer people will test as we grow the list of modules they must first
>>> install.
>> At worst, all we have to do is provide a script
>>
On Fri, Oct 6, 2017 at 5:57 AM, Craig Ringer wrote:
>> Fewer people will test as we grow the list of modules they must first
>> install.
>
> Meh, I don't buy that.
Well, I do. Prerequisites are a pain, and the more of them there are,
the more pain it is.
> At worst, all
On 10/13/2017 01:04 AM, Noah Misch wrote:
> On Fri, Oct 06, 2017 at 05:57:24PM +0800, Craig Ringer wrote:
>> On 6 October 2017 at 14:03, Noah Misch wrote:
>>> On Fri, Sep 08, 2017 at 10:32:03PM -0400, Tom Lane wrote:
(I do kinda wonder why we rolled our own
On Fri, Oct 06, 2017 at 05:57:24PM +0800, Craig Ringer wrote:
> On 6 October 2017 at 14:03, Noah Misch wrote:
> > On Fri, Sep 08, 2017 at 10:32:03PM -0400, Tom Lane wrote:
> >> (I do kinda wonder why we rolled our own RecursiveCopy; surely there's
> >> a better implementation
On 6 October 2017 at 14:03, Noah Misch wrote:
> On Fri, Sep 08, 2017 at 10:32:03PM -0400, Tom Lane wrote:
>> (I do kinda wonder why we rolled our own RecursiveCopy; surely there's
>> a better implementation in CPAN?)
>
> Fewer people will test as we grow the list of modules
On Fri, Sep 08, 2017 at 10:32:03PM -0400, Tom Lane wrote:
> (I do kinda wonder why we rolled our own RecursiveCopy; surely there's
> a better implementation in CPAN?)
Fewer people will test as we grow the list of modules they must first install.
Bundling a copy is tempting, but most CPAN modules
Michael Paquier writes:
> On Mon, Sep 11, 2017 at 11:55 PM, Tom Lane wrote:
>> 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?
> That
On Mon, Sep 11, 2017 at 11:55 PM, Tom Lane wrote:
> 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?
That looks good to me. I have tried pretty hard to break it, but
Michael Paquier writes:
> On Sun, Sep 10, 2017 at 12:38 AM, Tom Lane 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
On Sun, Sep 10, 2017 at 12:38 AM, Tom Lane wrote:
> Michael Paquier writes:
>> On Sat, Sep 9, 2017 at 1:43 PM, Tom Lane wrote:
>>> Yeah, even if we fixed this particular call site, I'm sure the issue
>>> would come up again.
Michael Paquier writes:
> On Sat, Sep 9, 2017 at 1:43 PM, Tom Lane wrote:
>> 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.
On Sat, Sep 9, 2017 at 1:43 PM, Tom Lane wrote:
> Michael Paquier 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
Michael Paquier writes:
> On Sat, Sep 9, 2017 at 11:32 AM, Tom Lane 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
On Sat, Sep 9, 2017 at 11:32 AM, Tom Lane 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? Just wondering if that's actually the slowest
one or not to run the full set of recovery
In a moment of idleness I tried to run the TAP tests on pademelon,
which is a mighty old and slow machine. Behold,
src/test/recovery/t/010_logical_decoding_timelines.pl fell over,
with the relevant section of its log contents being:
# testing logical timeline following with a filesystem-level
15 matches
Mail list logo