About the pid and opts files

I'm making consistent accessor functions to all of the special file names
used in the backend (e.g., "pg_hba.conf", "pg_control", etc.) and I got to
the pid file stuff. I'm wondering why you call the SetPidFile and
SetOptsFile functions twice, once in pmdaemonize() and once in the
non-detach case. It seems to me that you would get the same thing if you
just did:

if (silentflag)
pmdaemonize(); /* old version */

SetPidFile(...);
on_proc_exit(UnlinkPidFile, NULL);
SetOptsFile(...);

Is there anything special you wanted to achieve with this?

Becasue errors on creating the pid file and the opts file are
critical, I wanted to print error messages to stdout/stderr. After
detaching ttys, it would be impossible.

Furthermore, with the new run-time configuration system there will be a
fairly volatile set of possible options to the postmaster (and perhaps
more importantly, not all options are necessarily from the command line),
so the SetOptsFile function will need some rework. I think instead of
teaching SetOptsFile about each option that the postmaster might accept we
could just do

for (i=1; i<argc; i++)
{
fprintf(opts_file, "'%s' ", argv[i]);
}

The result wouldn't look as pretty as it does now but at least it would
always be correct. Comments?

Yes, the new run-time configuration system should simplify
SetOptsFile. But before proceeding further, I would like to learn more
about it. i.e. what kind of application interfaces are provided? Do
shell scripts such as pg_ctl can use it? Is there any documentation?
--
Tatsuo Ishii

Tatsuo Ishii writes:

Yes, the new run-time configuration system should simplify
SetOptsFile. But before proceeding further, I would like to learn more
about it. i.e. what kind of application interfaces are provided? Do
shell scripts such as pg_ctl can use it? Is there any documentation?

http://www.postgresql.org/docs/postgres/runtime-config.htm

The main difference is that formerly you could assume that if port = 6543
then the user necessarily gave the -p option (which isn't quite true if he
used the environment variable, but anyway). Now the user could have put
port = 6543 in the configuration file (postgresql.conf) and maybe the
reason he restarted the server was because he changed the port number
there. So reusing postmaster.opts blindly would be fatal. The solution is
as I illustrated to only write actual argv arguments to the file.

I have most of the coding done, btw. and it works well.

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

I wrote:

The main difference is that formerly you could assume that if port = 6543
then the user necessarily gave the -p option (which isn't quite true if he
used the environment variable, but anyway).

It occurred to me, we really do need to save the environment of the
postmaster. Consider such variables as LANG, LC_*, PATH (to find
executable), PGPORT, PGDATESTYLE, TZ. I think the safest thing is to just
save them all, unless you want to select the ones that matter.

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

Peter Eisentraut <peter_e@gmx.net> writes:

It occurred to me, we really do need to save the environment of the
postmaster. Consider such variables as LANG, LC_*, PATH (to find
executable), PGPORT, PGDATESTYLE, TZ.

Particularly the locale-related env vars. I think it is a serious
bug in the current system that it is possible to start the postmaster
with locale vars different from the values in effect at initdb time.
You can corrupt your text-column indices completely that way, because
the sort ordering an index depends on can change from run to run.

(We've only seen one or two bug reports we could trace to this, AFAIR,
but I'm surprised we don't see a steady stream of 'em. It's just too
easy to screw up if you sometimes start your postmaster from an
interactive environment and sometimes from system boot scripts.)

An opts file is not a reliable solution --- initdb ought to be recording
all the locale-relevant variables in pg_control, or some such NON user
editable place, and postmaster or backend startup ought to force those
values to be re-adopted.

PGDATESTYLE/TZ are not dangerous as far as I know; it should be allowed
for the user to change these.

regards, tom lane

Particularly the locale-related env vars. I think it is a serious
bug in the current system that it is possible to start the postmaster
with locale vars different from the values in effect at initdb time.
You can corrupt your text-column indices completely that way, because
the sort ordering an index depends on can change from run to run.

Our upcoming work on character sets should include this area as an
issue. We haven't yet discussed how and where "locale" is used, but its
effects may be more isolated once we allow multiple character sets in an
installation.

- Thomas

Tom Lane writes:

PGDATESTYLE/TZ are not dangerous as far as I know; it should be
allowed for the user to change these.

But in the context of pg_ctl we should certainly ensure that the old value
gets carried over unless overridden. We could make the postmaster.opts
file look like this:

PGDATESTYLE=${PGDATESTYLE-oldvalue} TZ=${TZ-oldvalue} ... postmaster ...

But I'm not sure if that is safe enough. If you want to change the
environment you can either edit postmaster.opts or do an explicit
stop/start rather than restart.

Failure scenario: Normally, TZ is unset. I log in remotely from a
different time zone to administer a database server so I have TZ set to
override the system's default time zone. I `su postgres', do something,
pg_ctl restart. All the sudden the server operates with a different
default time zone. This is not an unrealistic situation, I have done this
many times. If pg_ctl wants to automate things then it shouldn't be
subject to these sort of failures if possible.

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

Peter Eisentraut <peter_e@gmx.net> writes:

Failure scenario: Normally, TZ is unset. I log in remotely from a
different time zone to administer a database server so I have TZ set to
override the system's default time zone. I `su postgres', do something,
pg_ctl restart. All the sudden the server operates with a different
default time zone. This is not an unrealistic situation, I have done this
many times.

Right --- it should be *possible* to change these vars, but it should
take some explicit action. Having a different value in your environment
at postmaster start time is probably not enough of an explicit action.

This whole thread makes me more and more uncomfortable about the fact
that the postmaster/backend pay attention to environment variables at
all. An explicit configuration file would seem a better answer.

regards, tom lane

Tom Lane wrote:

Right --- it should be *possible* to change these vars, but it should
take some explicit action. Having a different value in your environment
at postmaster start time is probably not enough of an explicit action.

This whole thread makes me more and more uncomfortable about the fact
that the postmaster/backend pay attention to environment variables at
all. An explicit configuration file would seem a better answer.

Why a configuration file? Why not a configuration table?

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

Tom Lane wrote:

Right --- it should be *possible* to change these vars, but it should
take some explicit action. Having a different value in your environment
at postmaster start time is probably not enough of an explicit action.

This whole thread makes me more and more uncomfortable about the fact
that the postmaster/backend pay attention to environment variables at
all. An explicit configuration file would seem a better answer.

Why a configuration file? Why not a configuration table?

Circularity. A lot of this stuff has to be known before we dare touch
the database at all.

regards, tom lane

Tom Lane wrote:

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

Tom Lane wrote:

Right --- it should be *possible* to change these vars, but it should
take some explicit action. Having a different value in your environment
at postmaster start time is probably not enough of an explicit action.

This whole thread makes me more and more uncomfortable about the fact
that the postmaster/backend pay attention to environment variables at
all. An explicit configuration file would seem a better answer.

Why a configuration file? Why not a configuration table?

Circularity. A lot of this stuff has to be known before we dare touch
the database at all.

Aren't there other things like pg_database that survive this problem?

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

Why a configuration file? Why not a configuration table?

Circularity. A lot of this stuff has to be known before we dare touch
the database at all.

Aren't there other things like pg_database that survive this problem?

Er, have you dug into the code that does the initial access of
pg_database? I want to get rid of that kluge, not add more...

regards, tom lane

Then <tgl@sss.pgh.pa.us> spoke up and said:

Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:

Aren't there other things like pg_database that survive this problem?

Er, have you dug into the code that does the initial access of
pg_database? I want to get rid of that kluge, not add more...

This is why Ingres and Oracle (and probably others) use a text
parameter file to start up their databases.

--
=====================================================================
| JAVA must have been developed in the wilds of West Virginia. |
| After all, why else would it support only single inheritance?? |
=====================================================================
| Finger geek@cmu.edu for my public key. |
=====================================================================