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

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: "buffer too small" or "path too long"?
Дата
Msg-id YqfqgOKUV2RHyvRE@paquier.xyz
обсуждение исходный текст
Ответ на Re: "buffer too small" or "path too long"?  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Ответы Re: "buffer too small" or "path too long"?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: "buffer too small" or "path too long"?  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Список 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.ntt@gmail.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

Вложения

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

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