Re: [HACKERS] Re: Sure enough, the lock file is gone
Florent Guillaume: /tmp is for *temporary* files. Such a lock is not a temporary file, it should go somewhere in /var, why not in /var/lib/pgsql/data ? /var/run ? -- Alessio F. Bragadini[EMAIL PROTECTED]
Re: [HACKERS] Re: [GENERAL] MySQL - Postgres dump converter
On 27 Jan 2001 11:25:56 +0100 Adrian Phillips [EMAIL PROTECTED] wrote: "Max" == Max Rudensky [EMAIL PROTECTED] writes: Max Guys, Thomas said he won't look into GPL'ed code for ideas. Max Well, I re-read GPL and found that it's up to author whether Max is to allow or not to use code for using in programs with Max another open-source license. So this isn't a problem - you Max may use my program and include code to your without Max limitations. I even would prefer to change license to BSD or Max similar but I didn't find in GPL ideas about that. If you are the original author and have not had large contributions to it then its just a matter of rereleasing as BSD, if on the other hand others have contributed then you'll have to get permission from them. Yes, I wrote it, and I'd like to re-release it to other from GPL license. Sincerely, Adrian Phillips -- Your mouse has moved. Windows NT must be restarted for the change to take effect. Reboot now? [OK]
Re: [HACKERS] Re: Sure enough, the lock file is gone
Trond Eivind Glomsrd wrote: Tom Lane [EMAIL PROTECTED] writes: It would probably be better if the socket files weren't in /tmp but in a postgres-owned directory. However, at this point we have a huge backwards compatibility problem to overcome if we want to move the socket files. Not to sound scheptical, but since when did postgresql care about backwards compatiblity? Upgrading is already demanding a lot of knowledge from the user (including needing such information, which almost no other package do), this is just a minor change (the files are mostly used by bundled tools - any exceptions?) Upgrading is only one facet of backwards compatibility. When the fe-be protocol was changed for 6.4.2 is a good example. The SQL itself is kept very backwards-compatible, on purpose. Things for backwards-compatibility are not as bad as the upgrading situation would seem to imply. There is an option in 7.1 to support defining a different directory for the socket files, but I doubt very many people will use it. I intend to, for the RPMs we ship. Ok, why not fix tmpwatch instead? Only the lock files break FHS -- the sockets can go there by FHS, right? Of course, our requirement that they be in the same location sort of forces the issue. But, 7.1 now touches the locks enought to keep tmpwatch from blowing them out. To where do you intend to move them to? /var/lock/pgsql? /var/run/pgsql? (Or postgresql... I'm still not happy with that change -- the configuration is much nicer, but now the 'postgresql' suffix is fixed -- I'm probably going to have to patch that to pgsql, as I'm already changing many things that I'd prefer to leave closer to what 7.0 had). The change in question is the use of '/usr/share/postgresql' and '/usr/include/postgresql' as part of the installation, rather than allowing '/usr/share/pgsql' and '/usr/include/pgsql' . O well -- I'm just going to have to see how it distills. I've not received any complaints yet, but I expect many after final. :-( -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] Re: Sure enough, the lock file is gone
Lamar Owen [EMAIL PROTECTED] writes: Trond Eivind Glomsrd wrote: Tom Lane [EMAIL PROTECTED] writes: It would probably be better if the socket files weren't in /tmp but in a postgres-owned directory. However, at this point we have a huge backwards compatibility problem to overcome if we want to move the socket files. Not to sound scheptical, but since when did postgresql care about backwards compatiblity? Upgrading is already demanding a lot of knowledge from the user (including needing such information, which almost no other package do), this is just a minor change (the files are mostly used by bundled tools - any exceptions?) Upgrading is only one facet of backwards compatibility. I know. I just mentioned one consistently painful aspect of it. There is an option in 7.1 to support defining a different directory for the socket files, but I doubt very many people will use it. I intend to, for the RPMs we ship. Ok, why not fix tmpwatch instead? Because it wouldn't be a fix, it would be a "lets workaround one specific app which does things in a bad way"-hack. /tmp isn't supposed be more than that... storing things there for more than than 10 days? Ouch. Only the lock files break FHS Explictly, yes. However, FHS says /tmp is for temporary files. Also, it says programs shouldn't count on data to be stored there between invocations. 10+ days isn't temporary... To where do you intend to move them to? /var/lock/pgsql? /var/run/pgsql? Ideally, the locks should be in /var/lock/pgsql and the socket somewhere else - like /var/lib/pgsql (our mysql packages do this, and both of them are specified in /etc/my.cnf). -- Trond Eivind Glomsrd Red Hat, Inc.
[HACKERS] Re: [ADMIN] Controlling user table creation
Peter Eisentraut wrote [re using rules to guard against unprivileged table creation]: It couldn't, because the CREATE TABLE code does not go through the rule system. Could it not be done by enforcing access control on system tables? At present this is partially supported. Perversely, I can deny select privilege to pg_class but cannot deny insert privilege: junk=# revoke all on pg_class from public; CHANGE junk=# \d List of relations Name | Type | Owner --+--+--- a| table| olly ... (14 rows) junk=# \c - ruth You are now connected as new user ruth. junk= \d ERROR: pg_class: Permission denied. junk= create table xx (id int); CREATE junk= \c - olly You are now connected as new user olly. junk=# \d List of relations Name | Type | Owner --+--+--- a| table| olly ... xx | table| ruth (15 rows) If the denial of write privilege were enforced, it would not be possible for an unprivileged user to create tables. When a database is created, all the system tables should be made read only for PUBLIC. As a corollary, when a write privilege is granted on a table, it may be necessary to give concomitant privilege on tables needed to update sequences and other such items (I can't think of any others, at the moment), or else by-pass privilege checking on these. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "Many are the afflictions of the righteous; but the LORD delivereth him out of them all." Psalm 34:19
Re: [HACKERS] Re: Sure enough, the lock file is gone
Trond Eivind Glomsrd wrote: Lamar Owen [EMAIL PROTECTED] writes: Trond Eivind Glomsrd wrote: Not to sound scheptical, but since when did postgresql care about backwards compatiblity? Upgrading is already demanding a lot of Upgrading is only one facet of backwards compatibility. I know. I just mentioned one consistently painful aspect of it. Your pain is evident from the hyperbolic statement. I share your pain. However, FHS says /tmp is for temporary files. Also, it says programs shouldn't count on data to be stored there between invocations. 10+ days isn't temporary... But postmaster _doesn't_ expect the files to stay _between_ invocations :-) But your point is understood. What about the X sockets, then? X might stay up 10+ days. X doesn't just put one file there, either -- there's a whole directory there in /tmp. To where do you intend to move them to? /var/lock/pgsql? /var/run/pgsql? Ideally, the locks should be in /var/lock/pgsql and the socket somewhere else - like /var/lib/pgsql (our mysql packages do this, and both of them are specified in /etc/my.cnf). According to what Peter said, that could be difficult. But, let me ask this: is it a good thing for PostgreSQL clients to have hard-coded socket locations? (Good thing or not, it exists already, and I know it does) I have another question of Peter, Tom, Bruce, or anyone -- is the hard-coded socket location in libpq? If so, wouldn't a dynamically loaded libpq.so bring this location in for _any_ precompiled, not statically-linked, client? Or am I missing something else? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
[HACKERS] Re: [ADMIN] Controlling user table creation
Oliver Elphick writes: Could it not be done by enforcing access control on system tables? No, because CREATE TABLE does not go through access control either. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Re: Sure enough, the lock file is gone
Lamar Owen writes: What about the X sockets, then? Sockets are not the problem, regular files are. (At least for tmpwatch.) But, let me ask this: is it a good thing for PostgreSQL clients to have hard-coded socket locations? (Good thing or not, it exists already, and I know it does) Perhaps there could be some sort of /etc/postgresql.conf file that is read by both client and server that can control these sort of aspects. But I don't see much use in it besides port number and socket location. Because those are, by definition, the only parameters in common to client and server. I have another question of Peter, Tom, Bruce, or anyone -- is the hard-coded socket location in libpq? If so, wouldn't a dynamically loaded libpq.so bring this location in for _any_ precompiled, not statically-linked, client? Yes. Good point. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Re: Sure enough, the lock file is gone
Peter Eisentraut wrote: Lamar Owen writes: But, let me ask this: is it a good thing for PostgreSQL clients to have hard-coded socket locations? (Good thing or not, it exists already, and I know it does) Perhaps there could be some sort of /etc/postgresql.conf file that is read by both client and server that can control these sort of aspects. But I don't see much use in it besides port number and socket location. Because those are, by definition, the only parameters in common to client and server. Of course, -i and TCP/IP to localhost obviate all of this. How about an environment variable? PGSOCKLOC? Use the hard-coded default if the envvar not set? This way multiple postmasters running on multiple sockets can be smoothly supported. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] Re: Sure enough, the lock file is gone
[EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: Ideally, the locks should be in /var/lock/pgsql and the socket somewhere else - like /var/lib/pgsql (our mysql packages do this, and both of them are specified in /etc/my.cnf). That is not "ideal", in fact it would break one of the specific features that UUNET asked us for. Namely, to be able to have noninterfering sets of socket files in different explicitly-specified directories. If the lock files don't live where the sockets do, then this doesn't work. Explictly, yes. However, FHS says /tmp is for temporary files. Also, it says programs shouldn't count on data to be stored there between invocations. 10+ days isn't temporary... We aren't counting on data to be stored in /tmp "between invocations". The socket and lock file live only as long as the postmaster runs. regards, tom lane
Re: [HACKERS] Re: Sure enough, the lock file is gone
Lamar Owen [EMAIL PROTECTED] writes: I have another question of Peter, Tom, Bruce, or anyone -- is the hard-coded socket location in libpq? If so, wouldn't a dynamically loaded libpq.so bring this location in for _any_ precompiled, not statically-linked, client? Or am I missing something else? As the 7.1 code presently stands, libpq contains a compiled-in default socketfile location, which the client code hopefully doesn't know about. So, yes, if an old client has a dynamically linked libpq.so then replacing the .so would bring that client into sync with a nonstandard server. However, the pitfalls should be obvious: independently built clients, statically linked libraries, differing .so version numbers to name three risk areas. regards, tom lane
Re: [HACKERS] Re: Sure enough, the lock file is gone
Peter Eisentraut [EMAIL PROTECTED] writes: Perhaps there could be some sort of /etc/postgresql.conf file that is read by both client and server that can control these sort of aspects. Maybe ... but it seems to me that still leaves us with the issue of a single pathname that must be known a-priori to both client and server. You've just changed that path from "/tmp/..." to "/etc/...". Moreover, such a setup would make it substantially more painful to run multiple versions of Postgres on a single machine. Right now, as long as each version has a different default port number, it works great. Try to put the default port number in /etc/postgresql.conf, and you've got a problem. regards, tom lane
Re: [HACKERS] Re: Sure enough, the lock file is gone
Tom Lane [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: Ideally, the locks should be in /var/lock/pgsql and the socket somewhere else - like /var/lib/pgsql (our mysql packages do this, and both of them are specified in /etc/my.cnf). (note that you AFAIK (I don't use mysql much, I prefer postgresql) can have multiple sections if you want want to have multiple backends running. That is not "ideal", in fact it would break one of the specific features that UUNET asked us for. Namely, to be able to have noninterfering sets of socket files in different explicitly-specified directories. If the lock files don't live where the sockets do, then this doesn't work. I don't see why this must be so... Explictly, yes. However, FHS says /tmp is for temporary files. Also, it says programs shouldn't count on data to be stored there between invocations. 10+ days isn't temporary... We aren't counting on data to be stored in /tmp "between invocations". Between invocations of client programs. You're using /tmp as a shared of stored data. -- Trond Eivind Glomsrd Red Hat, Inc.
Re: [HACKERS] Re: Sure enough, the lock file is gone
Tom Lane wrote: So, yes, if an old client has a dynamically linked libpq.so then replacing the .so would bring that client into sync with a nonstandard server. Of course, with the server and client on the same machine, the server and the client dynamic libs are very likely to follow the same 'non-standard' as the libpq.so is likely to be from the same build or package as the server is. However, the pitfalls should be obvious: independently built clients, statically linked libraries, differing .so version numbers to name three risk areas. These are real risks, of course. I have personal experience with the statically linked client and differing so version number cases. And, yes, to echo your previous sentiment, if it breaks, the distributor/packager is not the one that gets the compliants -- the PostgreSQL community does. So, for future discussion, a compromise will have to be arranged -- but this really isn't a 7.1 issue, as this isn't a 'bugfix' per se -- you have fixed the immediate problem. But this is something to consider for 7.2 or later, as priorities are shuffled. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
[HACKERS] Development of ISO19100 support in PG
Hi, The FMaps team is about to build ISO19100 support in PG, in particulary Spatial Schema and Metadata schema. The project is at its early stages, but most of the technical hurdles are understood, so we are now left with coding the specifications. If you would like to join or are interested, please have a look on http://FMaps.sourceforge.net/ and inside the src/geoobj directory of the CVS. The project will build an extension library to PG, which may be included later in main stream PG if everybody find this stuff great. Thanks. Franck Martin Network and Database Development Officer SOPAC South Pacific Applied Geoscience Commission Fiji E-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Web site: http://www.sopac.org/ http://www.sopac.org/ Support FMaps: http://fmaps.sourceforge.net/ http://fmaps.sourceforge.net/ This e-mail is intended for its addresses only. Do not forward this e-mail without approval. The views expressed in this e-mail may not be necessarily the views of SOPAC.
Re: [HACKERS] Re: Sure enough, the lock file is gone
Lamar Owen [EMAIL PROTECTED] writes: How about an environment variable? PGSOCKLOC? Use the hard-coded default if the envvar not set? This way multiple postmasters running on multiple sockets can be smoothly supported. It's spelled PGHOST as of 7.1 ... but the discussion here is about what the default behavior of an installation will be, not what you can override it to do. regards, tom lane
Re: [HACKERS] Re: Sure enough, the lock file is gone
[EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: Explictly, yes. However, FHS says /tmp is for temporary files. Also, it says programs shouldn't count on data to be stored there between invocations. 10+ days isn't temporary... We aren't counting on data to be stored in /tmp "between invocations". Between invocations of client programs. You're using /tmp as a shared of stored data. Huh? The socket and lockfile are created and held open by the postmaster for the duration of its run. Client programs don't even know that the lockfile is there, in fact. How can you argue that client program lifespan has anything to do with it? regards, tom lane
Re: [HACKERS] Re: Sure enough, the lock file is gone
Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: How about an environment variable? PGSOCKLOC? Use the hard-coded default if the envvar not set? This way multiple postmasters running on multiple sockets can be smoothly supported. It's spelled PGHOST as of 7.1 ... but the discussion here is about what the default behavior of an installation will be, not what you can override it to do. I'm talking about Unix domain socket location, not TCP/IP hostname, which PGHOST is, right? But you are very right -- this doesn't help the default. The FHS-mandated place for such a configuration file detailing such settings is in /etc -- but, of course, we support installations that have been installed by a non-root user. ISTM a 'pg_config --default-socket' command could be used to find the location, assuming pg_config is on the PATH. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] Re: Sure enough, the lock file is gone
Oliver Elphick wrote: No, UNIX sockets are specifically mentioned as belonging under /var/run. In section 5.10 "/var/run : Run-time variable data", it says: "Programs that maintain transient UNIX-domain sockets should place them in this directory." So what ever the outcome for the wider PostgreSQL community, I must make the change to conform to Debian policy. So, if PostgreSQL is a part of Debian, then there will be problems if the client-server situation isn't somehow fixed to allow robust location-independent socket finding. Looks like the same thing is going to happen with RedHat's distribution. So, if this is going to occur, let's get a consensus as to where that alternate location (barring some other solution) is going to be, so that there are the fewest variants out there. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] Re: Sure enough, the lock file is gone
Lamar Owen wrote: Tom Lane wrote: It's spelled PGHOST as of 7.1 ... but the discussion here is about what the default behavior of an installation will be, not what you can override it to do. I'm talking about Unix domain socket location, not TCP/IP hostname, which PGHOST is, right? Found the code in fe-connect.c that changes that assumption.sorry for my high density :-). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] Re: Sure enough, the lock file is gone
Tom Lane [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes: Explictly, yes. However, FHS says /tmp is for temporary files. Also, it says programs shouldn't count on data to be stored there between invocations. 10+ days isn't temporary... We aren't counting on data to be stored in /tmp "between invocations". Between invocations of client programs. You're using /tmp as a shared of stored data. Huh? The socket and lockfile are created and held open by the postmaster for the duration of its run. Client programs don't even know that the lockfile is there, in fact. How can you argue that client program lifespan has anything to do with it? Nothing but the postmaster uses it? If so, there shouldn't be a problem moving it. -- Trond Eivind Glomsrd Red Hat, Inc.
Re: [HACKERS] Re: Sure enough, the lock file is gone
Lamar Owen [EMAIL PROTECTED] writes: Oliver Elphick wrote: No, UNIX sockets are specifically mentioned as belonging under /var/run. In section 5.10 "/var/run : Run-time variable data", it says: "Programs that maintain transient UNIX-domain sockets should place them in this directory." So what ever the outcome for the wider PostgreSQL community, I must make the change to conform to Debian policy. So, if PostgreSQL is a part of Debian, then there will be problems if the client-server situation isn't somehow fixed to allow robust location-independent socket finding. Looks like the same thing is going to happen with RedHat's distribution. So, if this is going to occur, let's get a consensus as to where that alternate location (barring some other solution) is going to be, so that there are the fewest variants out there. FHS is a good starting (and end-) point. -- Trond Eivind Glomsrd Red Hat, Inc.
Re: [HACKERS] Re: Sure enough, the lock file is gone
Peter Eisentraut [EMAIL PROTECTED] writes: Perhaps there could be some sort of /etc/postgresql.conf file that is read by both client and server that can control these sort of aspects. Maybe ... but it seems to me that still leaves us with the issue of a single pathname that must be known a-priori to both client and server. You've just changed that path from "/tmp/..." to "/etc/...". And writing to /etc requires root permissions. That is the restriction that got us into /tmp in the first place. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Re: Sure enough, the lock file is gone
Lamar Owen [EMAIL PROTECTED] writes: Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: How about an environment variable? PGSOCKLOC? It's spelled PGHOST as of 7.1 ... I'm talking about Unix domain socket location, not TCP/IP hostname, which PGHOST is, right? No, in 7.1 PGHOST serves a dual purpose. If a hostname beginning with "/" is given, it's taken to specify Unix-socket communication using a socketfile in the directory whose absolute path is PGHOST. A tad crocky but it avoided having to add an additional parameter to the PQconnect family of functions ... Also, on the postmaster side, there is a postmaster commandline parameter to set the directory containing the socket files (and lockfiles). So it's possible for a given installation to configure the socketfiles anywhere without modifying the binaries at all. But you do need to set PGHOST on the client side to make this work. It all comes back to what the default is. Basically, what's bothering me is the idea that the RPM distribution will have a different default socket location than the regular source distribution. I think that will cause a lot more problems than it solves. regards, tom lane
Re: [HACKERS] Re: Sure enough, the lock file is gone
"Oliver Elphick" [EMAIL PROTECTED] writes: No, UNIX sockets are specifically mentioned as belonging under /var/run. In section 5.10 "/var/run : Run-time variable data", it says: "Programs that maintain transient UNIX-domain sockets should place them in this directory." So what ever the outcome for the wider PostgreSQL community, I must make the change to conform to Debian policy. Just out of curiosity, does Debian enforce a nonstandard location for X sockets as well? regards, tom lane
Re: [HACKERS] Re: Sure enough, the lock file is gone
On Sun, 28 Jan 2001, Tom Lane wrote: "Oliver Elphick" [EMAIL PROTECTED] writes: No, UNIX sockets are specifically mentioned as belonging under /var/run. In section 5.10 "/var/run : Run-time variable data", it says: "Programs that maintain transient UNIX-domain sockets should place them in this directory." So what ever the outcome for the wider PostgreSQL community, I must make the change to conform to Debian policy. Just out of curiosity, does Debian enforce a nonstandard location for X sockets as well? Just curious here ... there seems to have been *alot* of energy expended on this ... is there any reason why we don't just have a configuration option like other software has, that defaults to /tmp like we have it now, but that makes it easier for others to change it for their installs, as required?
[HACKERS] Beta4 available ...
Just wrap'd it up, if anyone want to take a quick peak ... will announce
it in the morning, just want to give the mirror sites a little bit of time
to pull it ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
Re: [HACKERS] Re: Sure enough, the lock file is gone
The Hermit Hacker [EMAIL PROTECTED] writes: Just curious here ... there seems to have been *alot* of energy expended on this ... is there any reason why we don't just have a configuration option like other software has, that defaults to /tmp like we have it now, but that makes it easier for others to change it for their installs, as required? We *have* such a configuration option, both compile-time and run-time, as of 7.1. The argument is about what the default should be, and in particular whether it's a good idea for certain binary distributions to have a different default than other distributions ... regards, tom lane
Re: [HACKERS] Re: Sure enough, the lock file is gone
On Sun, 28 Jan 2001, Bruce Momjian wrote: The bottom line: yes, /tmp was a poor choice of place to put the socket files. But no, it is not so poor as to be worth creating a Was it really a poor choice. Where else can we put it as non-root? ~pgsql/var/run? everything else was under that directory structure ...
Re: [HACKERS] Re: Sure enough, the lock file is gone
On Sun, 28 Jan 2001, Bruce Momjian wrote: The bottom line: yes, /tmp was a poor choice of place to put the socket files. But no, it is not so poor as to be worth creating a Was it really a poor choice. Where else can we put it as non-root? ~pgsql/var/run? everything else was under that directory structure ... Sure, but how do we hard-code where ~pgsql is located, unless we somehow check the home directory of pgsql, but then again, they really don't have to use the home directory of pgsql for the pgsql directory. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Re: Sure enough, the lock file is gone
Bruce Momjian [EMAIL PROTECTED] writes: The bottom line: yes, /tmp was a poor choice of place to put the socket files. But no, it is not so poor as to be worth creating a Was it really a poor choice. Where else can we put it as non-root? I would've favored something like /tmp/.postgres/socketfile, which is comparable to typical X11 setups. But it's moot, since we can't change the default path even that much without creating a compatibility headache ... regards, tom lane
Re: [HACKERS] Re: Sure enough, the lock file is gone
Bruce Momjian [EMAIL PROTECTED] writes: The bottom line: yes, /tmp was a poor choice of place to put the socket files. But no, it is not so poor as to be worth creating a Was it really a poor choice. Where else can we put it as non-root? I would've favored something like /tmp/.postgres/socketfile, which is comparable to typical X11 setups. But it's moot, since we can't change the default path even that much without creating a compatibility headache ... Agreed, that would have been better, but I don't see that buys us anything against the grim reaper. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Re: Sure enough, the lock file is gone
Bruce Momjian wrote: No one has suggested a location non-root people can put the socket/lock file, except /tmp, and IMHO, until we find one, the default stays in /tmp. Since RPM's _must_ be installed by root, that doesn't affect them. The debian packages are the same way. As long as the RPM contains the structures set as owned by 'postgres' (the default run user for postmaster), and the appropriate permissions are set, the directory could be anywhere, such as /var/run/pgsql. But there are of course problems with that approach, because libpq makes some hard-coded assumptions about where to look. The issue we have is that we don't assume root installs. Any root requirement is going to be RPM-specific. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Re: Sure enough, the lock file is gone
Lamar Owen [EMAIL PROTECTED] writes: But my issue is that libpq or any other client should be smart enough to not have to assume the location. Er, how do you propose to do that? The client cannot learn the correct location from the postmaster --- it must figure out *on its own* where the socket file is. AFAICS you can't avoid having hardwired knowledge about how to do that in the client. You or somebody else previously suggested hardwiring the location of a configuration file, rather than the socketfile itself, but I can't see that that really improves matters in this context. In particular, changing to such a method would still break backwards compatibility. regards, tom lane
Re: [HACKERS] Re: Sure enough, the lock file is gone
On Mon, 29 Jan 2001, Oliver Elphick wrote: It seems to me that the main reason for the problem is the need to cater for non-root installs. I would really like to know what PostgreSQL will _not_ run as root. Just try... :) morannon:~/usr/local/pgsql/bin/postmaster "root" execution of the PostgreSQL backend is not permitted. The backend must be started under its own userid to prevent a possible system security compromise. See the INSTALL file for more information on how to properly start the postmaster. morannon:~ proportion of total PostgreSQL installs they now are. We are 100% Are there still people who can only install PostgreSQL as a private application? Private application - or non-root application? -- Dominic J. Eidson "Baruk Khazad! Khazad ai-menu!" - Gimli --- http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/
[HACKERS] Can PyGreSQL be updated?
I got a bug report on the PyGreSQL version included with PostgreSQL 7.0.3: "version 3.1 pygresql is available and there's also a 3.2 beta. the packaged version is 2.4." The version in 7.1beta3 is only 2.5. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "My son, if sinners entice thee, consent thou not." Proverbs 1:10
Re: [HACKERS] Re: Sure enough, the lock file is gone
"Dominic J. Eidson" wrote: On Mon, 29 Jan 2001, Oliver Elphick wrote: It seems to me that the main reason for the problem is the need to cater for non-root installs. I would really like to know what PostgreSQL will _not_ run as root. Just try... :) I'm talking about the installation, not execution. By default, PostgreSQL will install in /usr/local/pgsql; most people will need root privilege to create that directory. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "My son, if sinners entice thee, consent thou not." Proverbs 1:10
Re: [HACKERS] Re: Sure enough, the lock file is gone
Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: But my issue is that libpq or any other client should be smart enough to not have to assume the location. Er, how do you propose to do that? The client cannot learn the correct location from the postmaster --- it must figure out *on its own* where the socket file is. AFAICS you can't avoid having hardwired knowledge about how to do that in the client. How does netstat find out? A simple netstat -a --unix|grep \.s\.PGSQL will get the full list of all postmaster sockets. A little 'cut' or 'awk' work is simple enough. I realize, of course, that netstat (and the underlying, on Linux, /proc/net/unix file) is not portable. On Linux, simply grep /proc/net/unix for the .s.PGSQL pattern and get the last column (or the column before that, with the inode information). Is there a portable way of listing the open unix domain sockets in this manner, then deducing from the socket path what you need to know? You or somebody else previously suggested hardwiring the location of a configuration file, rather than the socketfile itself, but I can't see that that really improves matters in this context. In particular, changing to such a method would still break backwards compatibility. Not me. The less hardwiring, the better, IMHO. And I'm glad you pointed me to the new (undocumented that I could find) usage of PGHOST. A dynamic socket finder (assuming no specific socket path has been passed) would not break backwards compatibility, as it would find the default /tmp case. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] Re: Sure enough, the lock file is gone
Lamar Owen [EMAIL PROTECTED] writes: How does netstat find out? netstat burrows around in kernel datastructures, is how. I don't see invoking netstat as a solution anyway. For one thing, it's drastically nonstandard; even if available, it varies in parameters and output format (your "simple example" draws a usage complaint on my box). Furthermore, a moderately security-conscious admin would probably choose to make netstat unavailable to unprivileged users, since it reveals an uncomfortably large amount about the activity of other users. A final complaint is that netstat would actually reveal *too much* information, since a netstat-based client would have no way to choose among multiple postmasters. (Please recall that one of the motivations for the UUNET patch was to allow multiple postmasters running with the same port number in different subdirectories. Hmm, I wonder how netstat shows socketfiles that are in chroot'd subtrees, or outside your own chroot ...) regards, tom lane
[HACKERS] 7.1beta4 RPMs.
Unless Marc makes changes to the beta4 tarball, there will be beta4 RPM's for you to play with shortly. Actually, they are uploading now :-). ftp://ftp.postgresql.org/pub/dev/test-rpms is the place. If changes are made, I'll rebuild as soon as I find out (probably 18 hours or so from now). - RPM changes since beta3: 1.) /usr/share/postgresql, /etc/postgresql, and /usr/include/postgresql changed back to pgsql, to match /var/lib/pgsql (which is not at all likely to change). 2.) Now rebuilds without having to have the -devel rpm installed. :-0 3.) More documentation in html under the docdir (/usr/doc/postgresql-7.1beta4 on redhat 6.2). 4.) Regression test dirs now have right ownership. Still to be done: README.rpm-dist updates. Full upgrade testing. -lib split. -contrib subpackage. others that I have forgotten at this point in the night. Regression may be run by installing at least the main package, the server subpackage, and the test subpackage. Then, start the postmaster (/etc/rc.d/init.d/postgresql start), which will initdb if needed, su to postgres, cd to /usr/share/pgsql/test/regress, and execute: ./pg_regress --schedule=parallel_schedule RPMs passed regression (except for locale errors) on my RedHat 6.2 devel machine. I have changed the absolute minimum from beta3-2. Please let me know any problems you find! I am for now leaving the 7.1beta3-2 RPMset up. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] Re: Sure enough, the lock file is gone
Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: How does netstat find out? netstat burrows around in kernel datastructures, is how. I don't see invoking netstat as a solution anyway. For one thing, it's drastically nonstandard; even if available, it varies in parameters I said as much as it wasn't portable. But I asked also if a portable way was available -- I do not currently know that answer to that, but I will be investigating such. (Please recall that one of the motivations for the UUNET patch was to allow multiple postmasters running with the same port number in different subdirectories. Hmm, I wonder how netstat shows socketfiles that are in chroot'd subtrees, or outside your own chroot ...) When were these 'UUNET' patches issued? I like the idea, but just curious. I don't recall them, in fact -- nor do I recall the discussion. I'll look it up in the archives later. Going to bed after a night of RPM'ing. As to the chroot vs netstat question, that is a good one. I have no chroot's in effect, so I can't test that one. So, if multiple postmasters are running on the same port in different dirs, it would be somewhat difficult to determine which should be the 'default' in the list. However, one would think an admin who has set up a multiple postmaster system of that sort wouldn't be relying on a default anyway -- but that is a dangerous assumption. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] 7.1beta4 RPMs.
Lamar Owen wrote: ftp://ftp.postgresql.org/pub/dev/test-rpms is the place. One note: for whatever reason the date on the uploaded RPM's has the wrong year -- but the timestamp on my local copy has the correct date. In any case, ignore the datestamp on those RPM's -- there were _not_ built a year ago on Sat, January 29, 2000. But, they _are_ up for your RPM'ing pleasure. Please try to rebuild from source on whatever machine you have -- te more reports, the better the RPM. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
