Tom Lane wrote:
> 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.
Actually the backend never calls get_progname(), only the postmaster
does. I added a comment in path.c and postmaster.c about the possible
call to exit. I think this cleans it up as well as possible.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
