Re: "buffer too small" or "path too long"?
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
pgsql-hackers@lists.postgresql.org
Date: 2022-06-14T02:04:14Z
Lists: pgsql-hackers
Michael Paquier <michael@paquier.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
Commits
-
pg_upgrade: further tweaking of make_outputdirs().
- 4e54d231aecb 15.0 landed
-
Improve frontend error logging style.
- 9a374b77fb53 15.0 cited