Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nAKxe-0007VK-Q2 for pgsql-hackers@arkaria.postgresql.org; Thu, 20 Jan 2022 00:05:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nAKxc-0006jZ-No for pgsql-hackers@arkaria.postgresql.org; Thu, 20 Jan 2022 00:05:52 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nAKxc-0006jQ-BZ for pgsql-hackers@lists.postgresql.org; Thu, 20 Jan 2022 00:05:52 +0000 Received: from mail-io1-xd35.google.com ([2607:f8b0:4864:20::d35]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nAKxV-0006Rm-2M for pgsql-hackers@lists.postgresql.org; Thu, 20 Jan 2022 00:05:51 +0000 Received: by mail-io1-xd35.google.com with SMTP id w7so4995568ioj.5 for ; Wed, 19 Jan 2022 16:05:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=EpXBWHvhdwFqk7Ek7o4GUdW2d4eoOU3Ob1IWVbnswC0=; b=Xim1SY5XJ5c3TjVLStJr08W1blM5KXcLJ3Eg3S9I1DoeeMvmmJf8QSJAB6+1BmigKF smymUnp9qUTA4/HOK2BYqGvi44uxn1gieebKfxkpX3jF0yNonJuRV0mwBYz0L0S68fCx uOWWhtpXcl2uGSZZYNkRzlvYhN8gSg43XH3n07tEddR6gcpK20ii7DAvjKRO6ds9zdds hFZ2P7t3IUweJw1i9J3/rRf1ZN+ElB6GkTOXahd66jJ3YfgFWblsC39TczbvAmUUNEdB 51yoCLq9TgZadg1UBLUyS8PQfxtBhjP1pKTZ4WTItMpFg+hU11cTvPlhjod/uv/qd6zk i/FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=EpXBWHvhdwFqk7Ek7o4GUdW2d4eoOU3Ob1IWVbnswC0=; b=h63hZ5ZdqttILtjWqNxkKKPa7BD79SIOwfP79/YPP+0p0Jkqk5X7Z2CNsA3y/7aUN8 kaGLP4tKQ/pSlPpvcjNeRNvi1ZYx4n3mrXA7ylW0dVH+C67GuejjOyeL/7/KjXC1YXRC 91GWTR2IIoyqeGrOI0zXmTSR1TW7PTe9su9a7JSK1OsipINj9MKeQTvRMutfARsORMzS ikY2JqDt6qXtZOo1bV/Xy2LwLs6uARXzdBt5E3Kr/Bsy4/ndx1ZxCpF0hzKabOy28IMZ Fd3oFCUuT5c1PXTPRUmdnKQtNbRWuPmWuf7PO+5fOATI7k005phXp2CxHzlcYiUmmj1G 2Uvg== X-Gm-Message-State: AOAM530y1/dUbrja3abAp/2XyDFM9otQ5wUEsK8yv6b/JkSTOWzLLWcQ 7fF1z6NTVS4G+pBovWanN8TVVQ== X-Google-Smtp-Source: ABdhPJxXFMvy9e4kttjEL2tBMwq4CbgR8A2undNohaQgOjw2fPDjZY0Wn6BVWOgcw1VnKp4R7T6SCA== X-Received: by 2002:a02:cd85:: with SMTP id l5mr14752313jap.38.1642637142069; Wed, 19 Jan 2022 16:05:42 -0800 (PST) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id s17sm727709iow.10.2022.01.19.16.05.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jan 2022 16:05:41 -0800 (PST) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id B89AE80086E; Wed, 19 Jan 2022 18:05:40 -0600 (CST) Date: Wed, 19 Jan 2022 18:05:40 -0600 From: Justin Pryzby To: Michael Paquier Cc: Tom Lane , Daniel Gustafsson , Peter Eisentraut , Andrew Dunstan , Bruce Momjian , pgsql-hackers@lists.postgresql.org Subject: Re: pg_upgrade should truncate/remove its logs before running Message-ID: <20220120000540.GG23027@telsasoft.com> References: <20211221033926.GX17618@telsasoft.com> <238201.1640184746@sss.pgh.pa.us> <20211222163611.GC17618@telsasoft.com> <20220108184857.GI14051@telsasoft.com> <20220111200307.GA14051@telsasoft.com> <20220112040813.GD14051@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Jan 19, 2022 at 05:13:18PM +0900, Michael Paquier wrote: > On Tue, Jan 11, 2022 at 10:08:13PM -0600, Justin Pryzby wrote: > > I asked about that before. Right now, it'll exit(1) when mkdir fails. > > > > I had written a patch to allow "." by skipping mkdir (or allowing it to fail if > > errno == EEXIST), but it seems like an awfully bad idea to try to make that > > work with rmtree(). I still don't know if it even needs to be configurable. > - Add some sanity check about the path used, aka no parent reference > allowed and the output path should not be a direct parent of the > current working directory. I'm not sure these restrictions are needed ? + outputpath = make_absolute_path(log_opts.basedir); + if (path_contains_parent_reference(outputpath)) + pg_fatal("reference to parent directory not allowed\n"); Besides, you're passing the wrong path here. > I have noticed a couple of incorrect things in the docs, and some > other things. It is a bit late here, so I may have missed a couple of > things but I'll look at this stuff once again in a couple of days. > + pg_upgrade, and is be removed after a successful remove "be" > + if (mkdir(log_opts.basedir, S_IRWXU | S_IRWXG | S_IRWXO)) S_IRWXG | S_IRWXO are useless due to the umask, right ? Maybe use PG_DIR_MODE_OWNER ? > + if (mkdir(log_opts.basedir, S_IRWXU | S_IRWXG | S_IRWXO)) > + pg_fatal("could not create directory \"%s\": %m\n", filename_path); > + if (mkdir(log_opts.dumpdir, S_IRWXU | S_IRWXG | S_IRWXO)) > + pg_fatal("could not create directory \"%s\": %m\n", filename_path); > + if (mkdir(log_opts.logdir, S_IRWXU | S_IRWXG | S_IRWXO)) > + pg_fatal("could not create directory \"%s\": %m\n", filename_path); You're printing the wrong var. filename_path is not initialized. -- Justin