2012-11-21 14:19 keltezéssel, Alvaro Herrera írta:
> Boszormenyi Zoltan wrote:
>
>> The problem is that it calls pg_malloc() which is an executable-specific
>> function. Some of the bin/* executables define it as calling exit(1)
>> when malloc() returns NULL, some call it with exit(EXIT_FAILURE)
>> which happens to be 1 but still can be different from the constant 1.
>> Some executables only define pg_malloc0() but not pg_malloc().
> It seems simpler to have the escape_quotes utility function in port just
> not use pg_malloc at all, have it return NULL or similar failure
> indicator when malloc() fails, and then the caller decides what to do.
$ find . -name "*.c" | xargs grep pg_malloc | grep -v "^pg_malloc" | wc -l
277
Too much work for little gain.
Also:
- pg_upgrade calls pg_log(PG_FATAL, ...)
- pgbench logs a line then calls exit(1)
What I can imagine is to introduce a new src/port/ function,
InitPostgresFrontend() or something like that. Every executable
then calls this function first inside their main() it they want to use
pg_malloc() from libpgport.a. This function would accept a pointer
to a structure, and the struct contains the pointer to the exit
function and the argument too call it with. Other data for different
use cases can be added later if needed.
This way, the pg_malloc() and friends can be unified and their call
interfaces don't have to change. InitPostgresFrontend() needs
to be added to only 9 places instead of changing 277 callers of
pg_malloc() or pg_malloc0().
BTW, the unified pg_malloc() and friends must be inside
#ifdef FRONTEND ... #endif to not leak into the backend code.
Opinions?
Best regards,
Zoltán Böszörményi
--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de http://www.postgresql.at/
