Re: "buffer too small" or "path too long"? - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: "buffer too small" or "path too long"?
Date
Msg-id 20220614.094826.1283128317216009573.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: "buffer too small" or "path too long"?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: "buffer too small" or "path too long"?
Re: "buffer too small" or "path too long"?
List pgsql-hackers
At Mon, 13 Jun 2022 13:25:01 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in 
> Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
> > The root cause of the errors is that the user-provided directory path
> > of new cluster's root was too long.  Anywhich one of the four buffers
> > is overflowed, it doesn't makes any difference for users and doesn't
> > offer any further detail to suppoerters/developers.  I see "output
> > directory path of new cluster too long" clear enough.
> 
> +1, but I'm inclined to make it read "... is too long".

Yeah, I feel so and it is what I wondered about recently when I saw
some complete error messages.  Is that because of the length of the
subject?

> > # And the messages are missing trailing line breaks.
> 
> 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].  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..)

[1] https://www.postgresql.org/message-id/941719.1645587865%40sss.pgh.pa.us

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Collation version tracking for macOS
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: "buffer too small" or "path too long"?