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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCH] pg_ctl should not truncate command lines at 1024 characters
Дата
Msg-id 2444029.1630627756@sss.pgh.pa.us
обсуждение исходный текст
Ответ на [PATCH] pg_ctl should not truncate command lines at 1024 characters  (Phil Krylov <phil@krylov.eu>)
Ответы Re: [PATCH] pg_ctl should not truncate command lines at 1024 characters  (Phil Krylov <phil@krylov.eu>)
Список pgsql-hackers
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: dup(0) fails on Ubuntu 20.04 and macOS 10.15 with 13.0
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [PATCH] test/ssl: rework the sslfiles Makefile target