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

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>, 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-15 06:51:26
Message-ID: 2fb5396d-8901-f88d-0cd5-0279e73a62b2@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 14.06.22 03:55, Michael Paquier wrote:
> 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.

We have this problem of long file names being silently truncated all
over the source code. Instead of equipping each one of them with a
length check, why don't we get rid of the fixed-size buffers and
allocate dynamically, as in the attached patch.

Attachment Content-Type Size
0001-pg_upgrade-Use-psprintf-in-make_outputdirs.patch text/plain 3.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2022-06-15 06:53:53 Re: Remove trailing newlines from pg_upgrade's messages
Previous Message houzj.fnst@fujitsu.com 2022-06-15 06:45:37 RE: Support logical replication of DDLs