On 08/03/2023 00:05, Daniel Gustafsson wrote:
> When skimming through pg_rewind during a small review I noticed the use of
> pipe_read_line for reading arbitrary data from a pipe, the mechanics of which
> seemed odd.
>
> Commit 5b2f4afffe6 refactored find_other_exec() and broke out pipe_read_line()
> as a static convenience routine for reading a single line of output to catch a
> version number. Many years later, commit a7e8ece41 exposed it externally in
> order to read a GUC from postgresql.conf using "postgres -C ..". f06b1c598
> also make use of it for reading a version string much like find_other_exec().
> Funnily enough, while now used for arbitrary string reading the variable is
> still "pgver".
>
> Since the function requires passing a buffer/size, and at most size - 1 bytes
> will be read via fgets(), there is a truncation risk when using this for
> reading GUCs (like how pg_rewind does, though the risk there is slim to none).
Good point.
> If we are going to continue using this for reading $stuff from pipes, maybe we
> should think about presenting a nicer API which removes that risk? Returning
> an allocated buffer which contains all the output along the lines of the recent
> pg_get_line work seems a lot nicer and safer IMO.
+1
> /*
> * Execute a command in a pipe and read the first line from it. The returned
> * string is allocated, the caller is responsible for freeing.
> */
> char *
> pipe_read_line(char *cmd)
I think it's worth being explicit here that it's palloc'd, or malloc'd
in frontend programs, rather than just "allocated". Like in pg_get_line.
Other than that, LGTM.
--
Heikki Linnakangas
Neon (https://neon.tech)
