Re: "buffer too small" or "path too long"?

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: "buffer too small" or "path too long"?
Date: 2022-06-14 01:55:12
Message-ID: YqfqgOKUV2RHyvRE@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 14, 2022 at 09:52:52AM +0900, Kyotaro Horiguchi wrote:
> At Tue, 14 Jun 2022 09:48:26 +0900 (JST), Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote in
>> 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 I found that it is alrady done. Thanks!

I have noticed this thread and 4e54d23 as a result this morning. If
you want to spread this style more, wouldn't it be better to do that
in all the places of pg_upgrade where we store paths to files? I can
see six code paths with log_opts.basedir that could do the same, as of
the attached. The hardcoded file names have various lengths, and some
of them are quite long making the generated paths more exposed to
being cut in the middle.
--
Michael

Attachment Content-Type Size
upgrade-paths.patch text/x-diff 4.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-06-14 02:04:14 Re: "buffer too small" or "path too long"?
Previous Message Peter Geoghegan 2022-06-14 01:41:17 Re: Tightening behaviour for non-immutable behaviour in immutable functions