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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: "buffer too small" or "path too long"?
Дата
Msg-id 516480.1655316123@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: "buffer too small" or "path too long"?  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: "buffer too small" or "path too long"?  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Jun 15, 2022 at 2:51 AM Peter Eisentraut
> <peter.eisentraut@enterprisedb.com> wrote:
>> 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.

> I don't know how much we gain by fixing one place and not all the
> others, but maybe it would set a trend.

Yeah, that was what was bugging me about this proposal.  Removing
one function's dependency on MAXPGPATH isn't much of a step forward.

I note also that the patch leaks quite a lot of memory (a kilobyte or
so per pathname, IIRC).  That's probably negligible in this particular
context, but anyplace that was called more than once per program run
would need to be more tidy.

            regards, tom lane



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

Предыдущее
От: Nathan Bossart
Дата:
Сообщение: Re: docs: mention "pg_read_all_stats" in "track_activities" description
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Using PQexecQuery in pipeline mode produces unexpected Close messages