> > > 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.
> > Perhaps the timezone stuff is what needs to be moved. I'd be
> > surprised if there aren't eventually elog calls in src/timezone, so
> > thinking that timezone must work before elog does seems backwards.
> Magnus says the timezone stuff is being called somewhere he
> can't find, perhaps in some underlying library. Anyway, we
> can easily switch back to elog. It does have to get this
> info before processing GUC for sure.
Um. Not quite.
It certainly cannot be called from a *library* function. All our
functions are (in my new patch coming up) prefixed with pg_, so they'er
not called from a library.
But they are called very early at some point. In postmaster.c it worked
fine as it was, but in postgres.c it got called before it had
my_exec_path, and thus failed to find it's own libarry directory.
AFAIK the only ereport() or elog() in the timezone code is in
pg_timezone_initialize() (new function), and that one is called at a
fixed location after we have loaded the config file and thus have elog.
The main issue being that before we load the config file, we don't know
where to put our output, so it's not much point in doing it.
pgsql-committers by date
|Next:||From: Magnus Hagander||Date: 2004-05-19 08:06:09|
|Subject: Re: pgsql-server/src backend/main/main.c backend/p ...|
|Previous:||From: Bruce Momjian||Date: 2004-05-19 05:20:27|
|Subject: pgsql-server/src/test/regress pg_regress.sh|