Re: backup manifests and contemporaneous buildfarm failures - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: backup manifests and contemporaneous buildfarm failures
Date
Msg-id CAA8=A7_Hq6k02c1sKqvxDWUW9uHgA2if=84vHR9T95XSS040Dw@mail.gmail.com
Whole thread Raw
In response to Re: backup manifests and contemporaneous buildfarm failures  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
On Mon, Apr 6, 2020 at 1:18 AM Fabien COELHO <coelho@cri.ensmp.fr> wrote:
>
>
> Hello,
>
> >> Do I need to precede those with some recursive chmod commands? Perhaps
> >> the client should refuse to run if there is still something left after
> >> these.
> >
> > I think the latter would be a very good idea, just so that this sort of
> > failure is less obscure.  Not sure about whether a recursive chmod is
> > really going to be worth the cycles.  (On the other hand, the normal
> > case should be that there's nothing there anyway, so maybe it's not
> > going to be costly.)
>
> Could it be a two-stage process to minimize cost but still be resilient?
>
>    rmtree
>    if (-d $DIR) {
>      emit warning
>      chmodtree
>      rmtree again
>      if (-d $DIR)
>        emit error
>    }
>


I thought about doing that. However, it's not really necessary. In the
normal course of events these directories should have been removed at
the end of the previous run, so we're only dealing with exceptional
cases here.

cheers

andrew



-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: James Coleman
Date:
Subject: Re: [PATCH] Incremental sort (was: PoC: Partial sort)
Next
From: John Naylor
Date:
Subject: Re: Use compiler intrinsics for bit ops in hash