Re: pg_upgrade generated files in subdir follow-up

On Fri, Sep 09, 2022 at 11:07:41AM -0500, Justin Pryzby wrote:
> On Wed, Aug 31, 2022 at 04:41:24PM +0200, Daniel Gustafsson wrote:
> > > On 31 Aug 2022, at 15:59, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > > 
> > > Daniel Gustafsson <daniel@yesql.se> writes:
> > >> Commit 38bfae36526 moved the .txt files pg_upgrade generates to a separate
> > >> subdir, but there are a few left which are written to cwd.  The thread
> > >> resulting in that patch doesn't discuss these files specifically so it seems
> > >> they are just an oversight. Unless I'm missing something.
> > > 
> > >> Should something the attached be applied to ensure all generated files are
> > >> placed in the subdirectory?
> > > 
> > > It certainly looks inconsistent ATM.  I wondered if maybe the plan was to
> > > put routine output into the log directory but problem-reporting files
> > > into cwd --- but that isn't what's happening now.
> 
> The script files are intended to stay where they are, and the error
> files are intended to move under the subdir, to allow for their easy
> removal, per Tom's request.

Right.  The .txt files reporting that something went wrong should be
in the basedir, like loadable_libraries.txt, as these are not really
internal logs but provide information about a failure state.  I have
double-checked the whole code of pg_upgrade, and I am not seeing
another area to fix, so 0001 looks fine to me.  This one is on me, so
I guess that I'd like to take care of it myself.

> It looks like I may have grepped for fprintf or similar, and missed
> checking output_path.
> 
> I updated your patach to put the logic inside
> check_for_data_types_usage(), which is shorter, and seems to simplify
> doing what's intended into the future.

0002 makes the code more complicated IMO, as we still need to report
the location of the file in the logs.  So I would leave things to
what's proposed in 0001.
--
Michael