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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: "buffer too small" or "path too long"?
Дата
Msg-id 4024912.1655172254@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: "buffer too small" or "path too long"?  (Michael Paquier <michael@paquier.xyz>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: "buffer too small" or "path too long"?
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Tightening behaviour for non-immutable behaviour in immutable functions