From: Tom Lane <tgl@sss.pgh.pa.us>
To: Phil Krylov <phil@krylov.eu>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [PATCH] pg_ctl should not truncate command lines at 1024 characters
Date: Thu, 02 Sep 2021 20:09:16 -0400
Message-ID: <2444029.1630627756@sss.pgh.pa.us> (raw)
In-Reply-To: <567e199c6b97ee19deee600311515b86@krylov.eu>
References: <567e199c6b97ee19deee600311515b86@krylov.eu>
Phil Krylov <phil@krylov.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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, phil@krylov.eu
Subject: Re: [PATCH] pg_ctl should not truncate command lines at 1024 characters
In-Reply-To: <2444029.1630627756@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox