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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > >
> > > Daniel Gustafsson <daniel(at)yesql(dot)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