Re: pgsql-server/src backend/main/main.c backend/p ...

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Tom Lane wrote:
>> momjian(at)svr1(dot)postgresql(dot)org (Bruce Momjian) writes:
>>> Remove elog() calls from find_my_exec; do fprintf(stderr) instead.
>>
>> Isn't that a seriously bad idea?

> Yes, it probably is bad, but I am not sure how frequently this will
> happen, _and_ I need to set my_exec_path very far up in the tree to the
> timezone stuff knows the location, hence the fact that elog() calls
> wouldn't work at all anyway, I think.

The more I think about this, the less I like it.

find_my_exec and friends are *not* more critical to the backend than
elog is, and should not be done sooner. The argument that "we have to
find postgresql.conf before elog works" is specious --- elog will work
fine before we have read the config file, indeed had better do so since
guc.c uses elog to report problems. What will happen is that errors
will get reported to the compiled-in-default location, which happens to
be stderr at the moment. All you are accomplishing with this change is
to hard-wire that default and make it impossible to change in the
future.

Other concerns: I do not like changing random error reports from elog to
printf, firstly because it will encourage people to code other error
reports as printfs, which is something that took us a huge amount of
work to stamp out, and secondly because the requirement will propagate.
Are you going to avoid using palloc in find_my_exec, too? What about in
any subroutines that these things call?

I recommend reverting both this change and the ones to do find_my_exec
etc in main.c. You're better off doing these things where they were
done in PostmasterMain, PostgresMain, etc. palloc and elog are simply
fundamental parts of the backend programming environment; it does not
make sense to push complex functionality into a part of the code where
they aren't available.

regards, tom lane