From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: "buffer too small" or "path too long"? |
Date: | 2022-06-14 02:04:14 |
Message-ID: | 4024912.1655172254@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)xyz> writes:
> 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.
Well, I just fixed the ones in make_outputdirs because it seemed weird
that that part of the function was not doing something the earlier parts
did. I didn't look around for more trouble.
I think that pg_fatal'ing on the grounds of path-too-long once we've
already started the upgrade isn't all that great. Really we want to
fail on that early on --- so coding make_outputdirs like this is
fine, but maybe we need a different plan for files made later.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2022-06-14 02:32:42 | Re: Tightening behaviour for non-immutable behaviour in immutable functions |
Previous Message | Michael Paquier | 2022-06-14 01:55:12 | Re: "buffer too small" or "path too long"? |