vignesh C <vignes...@gmail.com> writes:
> createPQExpBuffer allocates memory and returns the pointer, there is a
> possibility that createPQExpBuffer can return NULL pointer in case of
> malloc failiure, but initdb's main function does not check this
> condition. During malloc failure when pointer is accessed it results
> in segmentation fault. Made changes to check and exit if
> createPQExpBuffer return's NULL pointer. Patch for the same is
> attached.
I can't get excited about this, for several reasons.
1) The probability of it happening in the field is not
distinguishable from zero, surely. I imagine you forced this
failure by making a debugging malloc fail occasionally.
2) If we really are out of memory at this point, we'd have just as good
odds that some allocation request inside pg_log_error() would fail.
There's no practical way to ensure that that code path remains free
of malloc attempts. (Not to mention cleanup_directories_atexit().)
3) In the end, an initdb failure is an initdb failure. This change
doesn't improve robustness by any useful metric, it just adds an
untestable code path. If we could recover somehow, it'd be more
interesting to spend time on.
BTW, looking at the small minority of places that bother to test
for createPQExpBuffer failure, the correct test for that seems
to be PQExpBufferBroken().
regards, tom lane
