Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> Somebody just yesterday stuck an
>> "fprintf(stderr,...); exit(1)" into one of the pgport routines. This
>> sucks, but there is not a lot else that can be done if the code needs
>> to exist in both backend and clients. It'd be better to propagate the
>> error condition back to the caller.
> Maybe you're referring to the patch I sent in to strip the .exe suffix
> in get_progname? ;-)
Yeah, that was it.
> I wondered about that. The choices on strdup() error seemed to be:
> . ignore the error and return the unstripped path, knowing the program
> would fail in a minute on the next malloc call anyway
> . return NULL and patch the code in about 20 places (of which one is the
> backend) where get_progname() is called
> . print a message and exit
Given the limited uses of get_progname, I think that "print a message
and exit" is fine; the problem is that the correct implementation of
that differs between backend and clients. The only really correct way
to log a message in the backend is elog/ereport --- there's no guarantee
that stderr connects to anything but /dev/null. Going directly to
exit() instead of proc_exit() is simply broken (although perhaps the
distinction does not matter, since the postmaster will treat exit(1) as
a backend crash and force a database-wide reset). If I thought that
this code path was ever likely to actually be taken in the field, I'd be
hollering much more loudly about it.
regards, tom lane