Re: [HACKERS] Still another race condition in recovery TAP tests

2017-10-16 Thread Michael Paquier
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 >>

Re: [HACKERS] Still another race condition in recovery TAP tests

2017-10-16 Thread Robert Haas
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

Re: [HACKERS] Still another race condition in recovery TAP tests

2017-10-13 Thread Andrew Dunstan
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

Re: [HACKERS] Still another race condition in recovery TAP tests

2017-10-12 Thread Noah Misch
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

Re: [HACKERS] Still another race condition in recovery TAP tests

2017-10-06 Thread Craig Ringer
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

Re: [HACKERS] Still another race condition in recovery TAP tests

2017-10-06 Thread Noah Misch
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

Re: [HACKERS] Still another race condition in recovery TAP tests

2017-09-11 Thread Tom Lane
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

Re: [HACKERS] Still another race condition in recovery TAP tests

2017-09-11 Thread Michael Paquier
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

Re: [HACKERS] Still another race condition in recovery TAP tests

2017-09-11 Thread Tom Lane
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

Re: [HACKERS] Still another race condition in recovery TAP tests

2017-09-10 Thread Michael Paquier
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.

Re: [HACKERS] Still another race condition in recovery TAP tests

2017-09-09 Thread Tom Lane
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.

Re: [HACKERS] Still another race condition in recovery TAP tests

2017-09-09 Thread Michael Paquier
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

Re: [HACKERS] Still another race condition in recovery TAP tests

2017-09-08 Thread Tom Lane
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

Re: [HACKERS] Still another race condition in recovery TAP tests

2017-09-08 Thread Michael Paquier
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

[HACKERS] Still another race condition in recovery TAP tests

2017-09-08 Thread Tom Lane
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