Re: pg_upgrade generated files in subdir follow-up - Mailing list pgsql-hackers

From Justin Pryzby
Subject Re: pg_upgrade generated files in subdir follow-up
Date
Msg-id 20220909160741.GM31833@telsasoft.com
Whole thread Raw
In response to Re: pg_upgrade generated files in subdir follow-up  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: pg_upgrade generated files in subdir follow-up
List pgsql-hackers
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, check_proper_datallowconn and check_for_isn_and_int8_passing_mismatch
> and a few other check functions already place error reporting in the subdir.

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.

-- 
Justin

Attachment

pgsql-hackers by date:

Previous
From: Japin Li
Date:
Subject: Re: Remove redundant code in pl_exec.c
Next
From: Nathan Bossart
Date:
Subject: Re: Avoid overhead with fprintf related functions