pgsql/src/backend/postmaster (postmaster.c)
Date: Monday, November 13, 2000 @ 10:18:11
Author: momjian
Update of /home/projects/pgsql/cvsroot/pgsql/src/backend/postmaster
from hub.org:/home/projects/pgsql/tmp/cvs-serv65584/pgsql/src/backend/postmaster
Modified Files:
postmaster.c
----------------------------- Log Message -----------------------------
UUNET is looking into offering PostgreSQL as a part of a managed web
hosting product, on both shared and dedicated machines. We currently
offer Oracle and MySQL, and it would be a nice middle-ground.
However, as shipped, PostgreSQL lacks the following features we need
that MySQL has:
1. The ability to listen only on a particular IP address. Each
hosting customer has their own IP address, on which all of their
servers (http, ftp, real media, etc.) run.
2. The ability to place the Unix-domain socket in a mode 700 directory.
This allows us to automatically create an empty database, with an
empty DBA password, for new or upgrading customers without having
to interactively set a DBA password and communicate it to (or from)
the customer. This in turn cuts down our install and upgrade times.
3. The ability to connect to the Unix-domain socket from within a
change-rooted environment. We run CGI programs chrooted to the
user's home directory, which is another reason why we need to be
able to specify where the Unix-domain socket is, instead of /tmp.
4. The ability to, if run as root, open a pid file in /var/run as
root, and then setuid to the desired user. (mysqld -u can almost
do this; I had to patch it, too).
The patch below fixes problem 1-3. I plan to address #4, also, but
haven't done so yet. These diffs are big enough that they should give
the PG development team something to think about in the meantime :-)
Also, I'm about to leave for 2 weeks' vacation, so I thought I'd get
out what I have, which works (for the problems it tackles), now.
With these changes, we can set up and run PostgreSQL with scripts the
same way we can with apache or proftpd or mysql.
In summary, this patch makes the following enhancements:
1. Adds an environment variable PGUNIXSOCKET, analogous to MYSQL_UNIX_PORT,
and command line options -k --unix-socket to the relevant programs.
2. Adds a -h option to postmaster to set the hostname or IP address to
listen on instead of the default INADDR_ANY.
3. Extends some library interfaces to support the above.
4. Fixes a few memory leaks in PQconnectdb().
The default behavior is unchanged from stock 7.0.2; if you don't use
any of these new features, they don't change the operation.
David J. MacKenzie
I have to agree with Peter E. on this patch: it's poorly thought out.
I don't mind the idea of being able to relocate the socket file,
but the client-side interface they've chosen is silly. Having to
add another switch to every client app is not reasonable --- it's
bad enough that you had to hack every one of the clients we supply,
but what of client apps that just use libpq or one of the other
interface libraries? They'll be unable to talk to such a postmaster
without further work.
We should revert all the client-side changes from this patch, and
instead teach libpq and the other interfaces to treat a host name
that starts with a slash as being a path to a socket file (replacing
the default assumption of "/tmp"). Much cleaner, especially for
existing client apps.
regards, tom lane
I have to agree with Peter E. on this patch: it's poorly thought out.
Now you tell me. :-)
I don't mind the idea of being able to relocate the socket file,
but the client-side interface they've chosen is silly. Having to
add another switch to every client app is not reasonable --- it's
bad enough that you had to hack every one of the clients we supply,
but what of client apps that just use libpq or one of the other
interface libraries? They'll be unable to talk to such a postmaster
without further work.
The only solution for other apps is to use the environment variable
PGUNXSOCKET or use PQconnectdb with unixsocket="lkjasdf".
Overloading the hostname with a leading slash is another nice option.
If I do that in libpq, then all the apps can benefit, right?
We should revert all the client-side changes from this patch, and
instead teach libpq and the other interfaces to treat a host name
that starts with a slash as being a path to a socket file (replacing
the default assumption of "/tmp"). Much cleaner, especially for
existing client apps.
I can easily back out whatever you want. Let me back out the client
changes, and hack libpq to handle the leading slash. Sounds good.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Actually, the thing doesn't even compile:
pqcomm.c: In function `StreamServerPort':
pqcomm.c:259: warning: implicit declaration of function `hstrerror'
pqcomm.c:259: `h_errno' undeclared (first use in this function)
pqcomm.c:259: (Each undeclared identifier is reported only once
pqcomm.c:259: for each function it appears in.)
make[3]: *** [pqcomm.o] Error 1
postmaster.c: In function `get_host_port':
postmaster.c:1338: warning: implicit declaration of function `hstrerror'
postmaster.c:1338: `h_errno' undeclared (first use in this function)
postmaster.c:1338: (Each undeclared identifier is reported only once
postmaster.c:1338: for each function it appears in.)
make[3]: *** [postmaster.o] Error 1
Please revert this patch, so I can get some work done?
regards, tom lane
Looks like it needs a resolver include....
LER
* Tom Lane <tgl@sss.pgh.pa.us> [001113 13:11]:
Actually, the thing doesn't even compile:
pqcomm.c: In function `StreamServerPort':
pqcomm.c:259: warning: implicit declaration of function `hstrerror'
pqcomm.c:259: `h_errno' undeclared (first use in this function)
pqcomm.c:259: (Each undeclared identifier is reported only once
pqcomm.c:259: for each function it appears in.)
make[3]: *** [pqcomm.o] Error 1postmaster.c: In function `get_host_port':
postmaster.c:1338: warning: implicit declaration of function `hstrerror'
postmaster.c:1338: `h_errno' undeclared (first use in this function)
postmaster.c:1338: (Each undeclared identifier is reported only once
postmaster.c:1338: for each function it appears in.)
make[3]: *** [postmaster.o] Error 1Please revert this patch, so I can get some work done?
regards, tom lane
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
On BSDI, hstrerror is defined in netdb.h. Do you have it anywhere? Is
that a proper function call?
Actually, the thing doesn't even compile:
pqcomm.c: In function `StreamServerPort':
pqcomm.c:259: warning: implicit declaration of function `hstrerror'
pqcomm.c:259: `h_errno' undeclared (first use in this function)
pqcomm.c:259: (Each undeclared identifier is reported only once
pqcomm.c:259: for each function it appears in.)
make[3]: *** [pqcomm.o] Error 1postmaster.c: In function `get_host_port':
postmaster.c:1338: warning: implicit declaration of function `hstrerror'
postmaster.c:1338: `h_errno' undeclared (first use in this function)
postmaster.c:1338: (Each undeclared identifier is reported only once
postmaster.c:1338: for each function it appears in.)
make[3]: *** [postmaster.o] Error 1Please revert this patch, so I can get some work done?
regards, tom lane
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Bruce Momjian <pgman@candle.pha.pa.us> writes:
On BSDI, hstrerror is defined in netdb.h. Do you have it anywhere? Is
that a proper function call?
There is no hstrerror anywhere on HPUX. h_errno is defined in
<netdb.h>, but only with nonstandard compilation options:
#ifdef _XOPEN_SOURCE_EXTENDED
extern int h_errno;
#endif
The man page for gethostbyname() points out that h_errno will be garbage
if the hostname was not resolved via a nameserver, anyway.
On the whole, this code looks much less than portable to me.
regards, tom lane
OK, hterror removed.
Bruce Momjian <pgman@candle.pha.pa.us> writes:
On BSDI, hstrerror is defined in netdb.h. Do you have it anywhere? Is
that a proper function call?There is no hstrerror anywhere on HPUX. h_errno is defined in
<netdb.h>, but only with nonstandard compilation options:#ifdef _XOPEN_SOURCE_EXTENDED
extern int h_errno;
#endifThe man page for gethostbyname() points out that h_errno will be garbage
if the hostname was not resolved via a nameserver, anyway.On the whole, this code looks much less than portable to me.
regards, tom lane
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Tom Lane writes:
We should revert all the client-side changes from this patch, and
instead teach libpq and the other interfaces to treat a host name
that starts with a slash as being a path to a socket file (replacing
the default assumption of "/tmp"). Much cleaner, especially for
existing client apps.
Should the parameter determine the directory or the full file name? I'd
go for the former, but it's not a strong case.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
Should the parameter determine the directory or the full file name? I'd
go for the former, but it's not a strong case.
Directory was what I had in mind too, but I'm not sure what Bruce
actually did ...
regards, tom lane
Peter Eisentraut <peter_e@gmx.net> writes:
Should the parameter determine the directory or the full file name? I'd
go for the former, but it's not a strong case.Directory was what I had in mind too, but I'm not sure what Bruce
actually did ...
I did whatever the patch did. I believe it is the full path. I believe
it is used here:
#define UNIXSOCK_PATH(sun,port,defpath) \
((defpath && defpath[0] != '\0') ? (strncpy((sun).sun_path,
defpath, sizeof((sun).sun_path)),
(sun).sun_path[sizeof((sun).sun_path)-1] = '\0') :
sprintf((sun).sun_path, "/tmp/.s.PGSQL.%d", (port)))
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Bruce Momjian <pgman@candle.pha.pa.us> writes:
Peter Eisentraut <peter_e@gmx.net> writes:
Should the parameter determine the directory or the full file name? I'd
go for the former, but it's not a strong case.Directory was what I had in mind too, but I'm not sure what Bruce
actually did ...
I did whatever the patch did. I believe it is the full path. I believe
it is used here:
#define UNIXSOCK_PATH(sun,port,defpath) \
((defpath && defpath[0] != '\0') ? (strncpy((sun).sun_path,
defpath, sizeof((sun).sun_path)),
(sun).sun_path[sizeof((sun).sun_path)-1] = '\0') :
sprintf((sun).sun_path, "/tmp/.s.PGSQL.%d", (port)))
Hmm. I think it would make more sense to make the parameter be just
the directory, not the full path including filename --- for one thing,
doing it like that renders the port-number parameter useless. Why not
#define UNIXSOCK_PATH(sun,port,defpath) \
snprintf((sun).sun_path, sizeof((sun).sun_path), "%s/.s.PGSQL.%d", \
(((defpath) && *(defpath) != '\0') ? (defpath) : "/tmp"), \
(port))
regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Peter Eisentraut <peter_e@gmx.net> writes:
Should the parameter determine the directory or the full file name? I'd
go for the former, but it's not a strong case.Directory was what I had in mind too, but I'm not sure what Bruce
actually did ...I did whatever the patch did. I believe it is the full path. I believe
it is used here:#define UNIXSOCK_PATH(sun,port,defpath) \
((defpath && defpath[0] != '\0') ? (strncpy((sun).sun_path,
defpath, sizeof((sun).sun_path)),
(sun).sun_path[sizeof((sun).sun_path)-1] = '\0') :
sprintf((sun).sun_path, "/tmp/.s.PGSQL.%d", (port)))Hmm. I think it would make more sense to make the parameter be just
the directory, not the full path including filename --- for one thing,
doing it like that renders the port-number parameter useless. Why not#define UNIXSOCK_PATH(sun,port,defpath) \
snprintf((sun).sun_path, sizeof((sun).sun_path), "%s/.s.PGSQL.%d", \
(((defpath) && *(defpath) != '\0') ? (defpath) : "/tmp"), \
(port))
I can do that. Of course, I have to now change all the documentation to
match it. :-)
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Bruce Momjian writes:
Hmm. I think it would make more sense to make the parameter be just
the directory, not the full path including filename --- for one thing,
doing it like that renders the port-number parameter useless. Why not#define UNIXSOCK_PATH(sun,port,defpath) \
snprintf((sun).sun_path, sizeof((sun).sun_path), "%s/.s.PGSQL.%d", \
(((defpath) && *(defpath) != '\0') ? (defpath) : "/tmp"), \
(port))I can do that. Of course, I have to now change all the documentation to
match it. :-)
Rather:
#define UNIXSOCK_PATH(sun,port,defpath) \
snprintf((sun).sun_path, sizeof((sun).sun_path), "%s/.s.PGSQL.%d", \
(defpath), (port))
and make "/tmp" the default in guc.c.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
#define UNIXSOCK_PATH(sun,port,defpath) \
snprintf((sun).sun_path, sizeof((sun).sun_path), "%s/.s.PGSQL.%d", \
(defpath), (port))
and make "/tmp" the default in guc.c.
No, because this has to work on the client side too. The default path
*must* be determined at compile time, or clients and servers will be
unable to find each other.
I wouldn't object to having "/tmp" be given as a macro PG_STD_SOCKET_DIR
in config.h, making it potentially configurable on a site-wide basis,
but that's as far as I think we can go.
regards, tom lane
Tom Lane writes:
#define UNIXSOCK_PATH(sun,port,defpath) \
snprintf((sun).sun_path, sizeof((sun).sun_path), "%s/.s.PGSQL.%d", \
(defpath), (port))and make "/tmp" the default in guc.c.
No, because this has to work on the client side too. The default path
*must* be determined at compile time, or clients and servers will be
unable to find each other.
The only difference between your snippet and mine is that yours sets the
default to "" and interprets it as "/tmp" when it is used, whereas mine
sets the default to "/tmp" to begin with. Clients don't see the
difference.
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
Tom Lane writes:
and make "/tmp" the default in guc.c.
No, because this has to work on the client side too. The default path
*must* be determined at compile time, or clients and servers will be
unable to find each other.
The only difference between your snippet and mine is that yours sets the
default to "" and interprets it as "/tmp" when it is used, whereas mine
sets the default to "/tmp" to begin with. Clients don't see the
difference.
Clients that don't contain guc.c are going to see a difference, no?
Where are they getting the default from?
regards, tom lane
Peter Eisentraut <peter_e@gmx.net> writes:
Tom Lane writes:
and make "/tmp" the default in guc.c.
No, because this has to work on the client side too. The default path
*must* be determined at compile time, or clients and servers will be
unable to find each other.The only difference between your snippet and mine is that yours sets the
default to "" and interprets it as "/tmp" when it is used, whereas mine
sets the default to "/tmp" to begin with. Clients don't see the
difference.Clients that don't contain guc.c are going to see a difference, no?
Where are they getting the default from?
Good point. This macro is called by the backend, and the libpq frontend
code. We would have to push the /tmp default into libpq code too, which
seems messier.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Bruce Momjian <pgman@candle.pha.pa.us> writes:
Peter Eisentraut <peter_e@gmx.net> writes:
Should the parameter determine the directory or the full file name? I'd
go for the former, but it's not a strong case.Directory was what I had in mind too, but I'm not sure what Bruce
actually did ...I did whatever the patch did. I believe it is the full path. I believe
it is used here:#define UNIXSOCK_PATH(sun,port,defpath) \
((defpath && defpath[0] != '\0') ? (strncpy((sun).sun_path,
defpath, sizeof((sun).sun_path)),
(sun).sun_path[sizeof((sun).sun_path)-1] = '\0') :
sprintf((sun).sun_path, "/tmp/.s.PGSQL.%d", (port)))Hmm. I think it would make more sense to make the parameter be just
the directory, not the full path including filename --- for one thing,
doing it like that renders the port-number parameter useless. Why not#define UNIXSOCK_PATH(sun,port,defpath) \
snprintf((sun).sun_path, sizeof((sun).sun_path), "%s/.s.PGSQL.%d", \
(((defpath) && *(defpath) != '\0') ? (defpath) : "/tmp"), \
(port))regards, tom lane
OK, here is the diff to make the socket file option specify just a
directory, not a full path. Documentation changes were also made.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026