Kyotaro Horiguchi <horikyota....@gmail.com> writes:
> At Mon, 13 Jun 2022 13:25:01 -0400, Tom Lane <t...@sss.pgh.pa.us> wrote in
>> I was about to question that, but now I remember that pg_upgrade has
>> its own logging facility with a different idea about who provides
>> the trailing newline than common/logging.[hc] has. Undoubtedly
>> that's the source of this mistake. We really need to get pg_upgrade
>> out of the business of having its own logging conventions.
> Yes... I don't find a written reason excluding pg_upgrade in both the
> commit 9a374b77fb and or the thread [1].
Well, as far as 9a374b77fb went, Peter had left pg_upgrade out of the
mix in the original creation of common/logging.c, and I didn't think
that dealing with that was a reasonable part of my update patch.
> But I guess that we decided
> that we first provide the facility in the best style ignoring the
> current impletent in pg_upgrade then let pg_upgrade use it. So I
> think it should emerge in the next cycle? I'll give it a shot if no
> one is willing to do that for now. (I believe it is straightforward..)
Actually, I spent some time earlier today looking into that, and I can
see why Peter stayed away from it :-(. There are a few issues:
* The inconsistency with the rest of the world about trailing newlines.
That aspect actually seems fixable fairly easily, and I have a patch
mostly done for it.
* logging.c believes it should prefix every line of output with the
program's name and so on. This doesn't seem terribly appropriate
for pg_upgrade's use --- at least, not unless we make pg_upgrade
WAY less chatty. Perhaps that'd be fine, I dunno.
* pg_upgrade's pg_log_v duplicates all (well, most) stdout messages
into the INTERNAL_LOG_FILE log file, something logging.c has no
provision for (and it'd not be too easy to do, because of the C
standard's restrictions on use of va_list). Personally I'd be okay
with nuking the INTERNAL_LOG_FILE log file from orbit, but I bet
somebody will fight to keep it.
* pg_log_v has also got a bunch of specialized rules around how
to format PG_STATUS message traffic. Again I wonder how useful
that whole behavior really is, but taking it out would be a big
user-visible change.
In short, it seems like pg_upgrade's logging habits are sufficiently
far out in left field that we couldn't rebase it on top of logging.c
without some seriously large user-visible behavioral changes.
I have better things to spend my time on than advocating for that.
However, the inconsistency in newline handling is a problem:
I found that there are already other bugs with missing or extra
newlines, and it will only get worse if we don't unify that
behavior. So my inclination for now is to fix that and let the
other issues go. Patch coming.
regards, tom lane
