On Mon, Jan 24, 2022 at 11:41:17AM -0600, Justin Pryzby wrote: > 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.
OK, thanks. There are really two cleanups --- first, the "log" directory, and second deletion of the old cluster by running delete_old_cluster.sh. -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
