Re: pg_upgrade should truncate/remove its logs before running

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pg_upgrade should truncate/remove its logs before running
Date: 2022-01-24 17:41:17
Message-ID: 20220124174117.GW23027@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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().
> ...
> >
> > <para>
> > <application>pg_upgrade</application> 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 <literal>pg_upgrade_output.d</literal> in
> > + the directory of the new cluster.
> > </para>
>
> 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);
}

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhihong Yu 2022-01-24 18:17:57 Re: Index Skip Scan (new UniqueKeys)
Previous Message Bruce Momjian 2022-01-24 17:39:30 Re: pg_upgrade should truncate/remove its logs before running