Re: [PATCH] pg_ctl should not truncate command lines at 1024 characters

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Phil Krylov <phil(at)krylov(dot)eu>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] pg_ctl should not truncate command lines at 1024 characters
Date: 2021-09-03 00:09:16
Message-ID: 2444029.1630627756@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Phil Krylov <phil(at)krylov(dot)eu> writes:
> IMHO pg_ctl should not blindly truncate generated command lines at
> MAXPGPATH (1024 characters) and then run that, resulting in:

Fair enough.

> The attached patch tries to fix it in the least intrusive way.

Seems reasonable. We didn't have psprintf when this code was written,
but now that we do, it's hardly any more complicated to do it without
the length restriction.

> While we're at it, is it supposed that pg_ctl is a very short-lived
> process and is therefore allowed to leak memory? I've noticed some
> places where I would like to add a free() call.

I think that these free() calls you propose to add are a complete
waste of code space. Certainly a free() right before an exit() call
is that; if anything, it's *delaying* recycling the memory space for
some useful purpose. But no part of pg_ctl runs long enough for it
to be worth worrying about small leaks.

I do not find your proposed test case to be a useful expenditure
of test cycles, either. If it ever fails, we'd learn nothing,
except that that particular platform has a surprisingly small
command line length limit.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-09-03 00:46:29 Re: [PATCH] test/ssl: rework the sslfiles Makefile target
Previous Message Tom Lane 2021-09-02 23:00:46 Re: dup(0) fails on Ubuntu 20.04 and macOS 10.15 with 13.0