Re: pipe_read_line for reading arbitrary strings

Daniel Gustafsson <daniel@yesql.se>

From: Daniel Gustafsson <daniel@yesql.se>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-09-25T07:55:36Z
Lists: pgsql-hackers

Attachments

> On 4 Jul 2023, at 14:50, Daniel Gustafsson <daniel@yesql.se> wrote:
> 
>> On 4 Jul 2023, at 13:59, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>> On 08/03/2023 00:05, Daniel Gustafsson wrote:
> 
>>> 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
> 
> Thanks for review!
> 
>>> /*
>>> * 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.
> 
> Good point, I'll make that happen before committing this.

Fixed, along with commit message wordsmithing in the attached.  Unless objected
to I'll go ahead with this version.

--
Daniel Gustafsson

Commits

  1. Fix errorhandling for reading from a pipe

  2. Refactor pipe_read_line to return the full line

  3. Add -c/--restore-target-wal to pg_rewind

  4. Here is a patch that fixes the pipes used in find_other_exec() when