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 1nC3Zm-0001EF-Ct for pgsql-hackers@arkaria.postgresql.org; Mon, 24 Jan 2022 17:56:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nC3Zl-0001yG-9e for pgsql-hackers@arkaria.postgresql.org; Mon, 24 Jan 2022 17:56:21 +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 1nC3Xi-0007T1-LK for pgsql-hackers@lists.postgresql.org; Mon, 24 Jan 2022 17:54:14 +0000 Received: from mail-io1-xd33.google.com ([2607:f8b0:4864:20::d33]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nC3LF-0002lq-Bq for pgsql-hackers@lists.postgresql.org; Mon, 24 Jan 2022 17:41:23 +0000 Received: by mail-io1-xd33.google.com with SMTP id h7so2517674iof.3 for ; Mon, 24 Jan 2022 09:41:20 -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=3rMOz7O0vUuKi9xw5EXVj0iKnEGW56ueks9Wl0x1Oe4=; b=M/gU8zvN2lpphxVeim2Xcno9Z7Eicf5mNnaeZPRAqqgCPg83v5733ztl6jb7T3OBUq e5+TS0+jwdrUYq7DLske+CPcT2myEQHUVG6L9jiNYSEwOLARr+4eE2f7EGdZJIpy1eTe sG+jKL0NRWEZ+aK/D85bvKGP9vZuCRCmhzxWC44g7v410MV9ceWc3t0XiBDxJitDECOi JkGlT7ZlRcbk/rLVVCV/s1bftU6VZTZ8hzgia3VR4UG7cbkEZlJuRHNcioeYFxoDc01E qwFHuE7ugs1cpkKrfFYrqDhXpQxl9EScgkIkMFzY8SFuV+s8Ys5C3NeMf9cZB2auaBm1 sb4A== 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=3rMOz7O0vUuKi9xw5EXVj0iKnEGW56ueks9Wl0x1Oe4=; b=Hi/V8q7ESIJzIqDXxxky2qZFkFZ9ezGAAuZdOsQektgNWBkIeJWynvPo2JpmPX7fxv OIGX1RXmAYPNyr9b2N3tUZNB3SNgRH0suBVTNCpHAu72bhD3RF0i9mW8Z/RG0uvTdcOK 4SL+gqiBiEm/HWUgmi88aTrJbeUpu92Uyd6XybAZtAXQLSNGv45payPMn6jjYdIoCUH7 oHZPZ231e4LkiyAoDiCJ2OAer+qhQi6Oia9x03ixfhbLEZWE+/2zeZ2cH/DbLpj06jh5 Zadg22pzZCQhgqPLZVuSiZiqd92qbin85Bv7WHuviSxS935bUsy59r0hyvns2KlYQDSZ 5Z0A== X-Gm-Message-State: AOAM533E9fK75IC50sClVJc8DqrhoRynBii4x4cs7GaXKuOgmtRvDNDr pTkvZwEPx2teWZPC5WC7Eu2Ybw== X-Google-Smtp-Source: ABdhPJy7OHicgYhslkKUGNkz1GiC0LbAVp5/BJJE08xsEVEORgHf8nb5qYheGAKtzeD+9qhQ4t1QjA== X-Received: by 2002:a02:c724:: with SMTP id h4mr4136563jao.260.1643046079276; Mon, 24 Jan 2022 09:41:19 -0800 (PST) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id 193sm1791433iob.17.2022.01.24.09.41.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Jan 2022 09:41:18 -0800 (PST) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id B3B91801AAA; Mon, 24 Jan 2022 11:41:17 -0600 (CST) Date: Mon, 24 Jan 2022 11:41:17 -0600 From: Justin Pryzby To: Bruce Momjian Cc: Michael Paquier , Peter Eisentraut , Tom Lane , Daniel Gustafsson , Andrew Dunstan , pgsql-hackers@lists.postgresql.org Subject: Re: pg_upgrade should truncate/remove its logs before running Message-ID: <20220124174117.GW23027@telsasoft.com> References: <20220108184857.GI14051@telsasoft.com> <20220111200307.GA14051@telsasoft.com> <20220112040813.GD14051@telsasoft.com> <45e7680a-b617-1397-afa0-35a793aacefe@enterprisedb.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 Mon, Jan 24, 2022 at 12:39:30PM -0500, Bruce Momjian wrote: > On Mon, Jan 24, 2022 at 10:59:40AM +0900, Michael Paquier wrote: > > On Thu, Jan 20, 2022 at 07:51:37PM +0900, Michael Paquier wrote: > > > Neat idea. That would work fine for my case. So I am fine to stick > > > with this suggestion. > > > > I have been looking at this idea, and the result is quite nice, being > > simpler than anything that has been proposed on this thread yet. We > > get a simpler removal logic, and there is no need to perform any kind > > of sanity checks with the output path provided as long as we generate > > the paths and the dirs after adjust_data_dir(). > ... > > > > > > pg_upgrade creates various working files, such > > - as schema dumps, in the current working directory. For security, be sure > > - that that directory is not readable or writable by any other users. > > + as schema dumps, stored within pg_upgrade_output.d in > > + the directory of the new cluster. > > > > Uh, how are we instructing people to delete that pg_upgrade output > directory? If pg_upgrade completes cleanly, would it be removed > automatically? Clearly. @@ -689,28 +751,5 @@ cleanup(void) /* Remove dump and log files? */ if (!log_opts.retain) - { - int dbnum; - char **filename; - - for (filename = output_files; *filename != NULL; filename++) - unlink(*filename); - - /* remove dump files */ - unlink(GLOBALS_DUMP_FILE); - - if (old_cluster.dbarr.dbs) - for (dbnum = 0; dbnum < old_cluster.dbarr.ndbs; dbnum++) - { - char sql_file_name[MAXPGPATH], - log_file_name[MAXPGPATH]; - DbInfo *old_db = &old_cluster.dbarr.dbs[dbnum]; - - snprintf(sql_file_name, sizeof(sql_file_name), DB_DUMP_FILE_MASK, old_db->db_oid); - unlink(sql_file_name); - - snprintf(log_file_name, sizeof(log_file_name), DB_DUMP_LOG_FILE_MASK, old_db->db_oid); - unlink(log_file_name); - } - } + rmtree(log_opts.basedir, true); }