Re: "buffer too small" or "path too long"? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: "buffer too small" or "path too long"?
Date
Msg-id 516480.1655316123@sss.pgh.pa.us
Whole thread Raw
In response to Re: "buffer too small" or "path too long"?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: "buffer too small" or "path too long"?  (Michael Paquier <michael@paquier.xyz>)
List 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 by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: docs: mention "pg_read_all_stats" in "track_activities" description
Next
From: Alvaro Herrera
Date:
Subject: Re: Using PQexecQuery in pipeline mode produces unexpected Close messages