From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: Mikael Kjellström <mikael.kjellstrom@mksoft.nu>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Fabien COELHO <coelho@cri.ensmp.fr>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: David Steele <david@pgmasters.net>
Cc: Andres Freund <andres@anarazel.de>
Cc: Noah Misch <noah@leadboat.com>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: Amit Kapila <amit.kapila16@gmail.com>
Cc: Suraj Kharage <suraj.kharage@enterprisedb.com>
Cc: tushar <tushar.ahuja@enterprisedb.com>
Cc: Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>
Cc: Rushabh Lathia <rushabh.lathia@gmail.com>
Cc: Tels <nospam-pg-abuse@bloodgate.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Cc: Jeevan Chalke <jeevan.chalke@enterprisedb.com>
Cc: vignesh C <vignesh21@gmail.com>
Cc: Thomas Munro <thomas.munro@gmail.com>
Subject: Re: backup manifests and contemporaneous buildfarm failures
Date: Sun, 05 Apr 2020 16:12:26 -0400
Message-ID: <4026.1586117546@sss.pgh.pa.us> (raw)
In-Reply-To: <95e52766-4e00-1bc7-8710-8b681760bdf4@2ndQuadrant.com>
References: <CA+TgmoazJ5wh+H77kjVfMnDh6WLh=oJodrwJ21SACSq5fojwPg@mail.gmail.com>
<20200403205412.GA8279@alvherre.pgsql>
<CA+TgmoaRbm-L1C2YkDVPx1TGN9ufxWjnaweTwKE=TQC-YOD=rg@mail.gmail.com>
<CA+TgmoZ4bAbjd_Am=UiMpBrgPEO=7YarqvaAMrQYKP1GkkOaRg@mail.gmail.com>
<alpine.DEB.2.21.2004032346550.16227@pseudo>
<22394.1585951968@sss.pgh.pa.us>
<CA+Tgmoah0khUqHG5vn8k=LJFO0mmNLyM3HtUmh4RBkq7W2GFgQ@mail.gmail.com>
<3419.1585965125@sss.pgh.pa.us>
<CA+TgmoYR6GKr1kc4KTBwXbNChDaJX8qnx7k+KKgtNnSiFgCumA@mail.gmail.com>
<10b8121c-faa1-66a7-4280-319b9be5cc2d@mksoft.nu>
<95e52766-4e00-1bc7-8710-8b681760bdf4@2ndQuadrant.com>
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> Hmm, the buildfarm client does this at the beginning of each run to
> remove anything that might be left over from a previous run:
> rmtree("inst");
> rmtree("$pgsql") unless ($from_source && !$use_vpath);
Right, the point is precisely that some versions of rmtree() fail
to remove a mode-0 subdirectory.
> 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.)
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andrew.dunstan@2ndquadrant.com, mikael.kjellstrom@mksoft.nu, robertmhaas@gmail.com, coelho@cri.ensmp.fr, alvherre@2ndquadrant.com, david@pgmasters.net, andres@anarazel.de, noah@leadboat.com, sfrost@snowman.net, amit.kapila16@gmail.com, suraj.kharage@enterprisedb.com, tushar.ahuja@enterprisedb.com, rajkumar.raghuwanshi@enterprisedb.com, rushabh.lathia@gmail.com, nospam-pg-abuse@bloodgate.com, jeevan.chalke@enterprisedb.com, vignesh21@gmail.com, thomas.munro@gmail.com
Subject: Re: backup manifests and contemporaneous buildfarm failures
In-Reply-To: <4026.1586117546@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox