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: 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.
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
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
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?
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/
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
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] Re: Sure enough, the lock file is gone
Florent Guillaume wrote: /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/lib is also not for locks, per FHS. /var/lock/pgsql (or /var/lock/postgresql) would be the FHS-mandated place for such a file. Comments? _Why_ is the lock in /tmp? Won't the lock always be put into place by the uid used to run postmaster? Is a _world_ writeable temporary directory the right place? 7.2 discussion, however, IMHO. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] Re: Sure enough, the lock file is gone
first off, the lock file is put in by an unprivileged user, so /tmp works
on all systems ...
second, /tmp on a large portion of systems gets cleaned out after a
reboot, so there are no 'stray locks' to generally worry about...
On Sat, 27 Jan 2001, Lamar Owen wrote:
Florent Guillaume wrote:
/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/lib is also not for locks, per FHS.
/var/lock/pgsql (or /var/lock/postgresql) would be the FHS-mandated
place for such a file.
Comments? _Why_ is the lock in /tmp? Won't the lock always be put into
place by the uid used to run postmaster? Is a _world_ writeable
temporary directory the right place?
7.2 discussion, however, IMHO.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
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 wrote: On Sat, 27 Jan 2001, Lamar Owen wrote: Comments? _Why_ is the lock in /tmp? Won't the lock always be put into place by the uid used to run postmaster? Is a _world_ writeable temporary directory the right place? first off, the lock file is put in by an unprivileged user, so /tmp works on all systems ... If /usr/local/pgsql (to use the default) is owned by the user running postmaster, then the postmaster has privileges to put the lockfile in, say, /usr/local/pgsql/lock/., right? Or am I missing something basic here? Is this lock placed by postmaster, or by something else? My 7.1beta3 installation shows two files in /tmp: srwxrwxrwx1 postgres postgres0 Jan 27 14:25 .s.PGSQL.5432 -rw---1 postgres postgres 25 Jan 27 14:25 .s.PGSQL.5432.lock I understand why the socket needs to be in /tmp, but why the lockfile? What or who is using the lockfile (which contains the pid of postmaster and the path to PGDATA for the postmaster)? second, /tmp on a large portion of systems gets cleaned out after a reboot, so there are no 'stray locks' to generally worry about... Ironic that RedHat, which can clean /tmp out on a cron basis would be one that doesn't clean it out by default on reboot. Lock file cleanup should be the responsibility of the script that starts postmaster -- or the responsibility of the DBA who manually starts and restarts postmasters, after crashes or at other times. Not a big issue, by any means. Just attempting to understand. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] Re: Sure enough, the lock file is gone
Lamar Owen writes: I understand why the socket needs to be in /tmp, but why the lockfile? The lock file protects the Unix domain socket. Consequently, the name of the lock file needs to be derivable from the name of the socket file, and vice versa. Also, the name of the socket file must not vary with other parameters such as installation layout. Lock file cleanup should be the responsibility of the script that starts postmaster The postmaster does that itself. That's why the pid is in there. -- 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: I understand why the socket needs to be in /tmp, but why the lockfile? The lock file protects the Unix domain socket. Consequently, the name of the lock file needs to be derivable from the name of the socket file, and vice versa. Also, the name of the socket file must not vary with other parameters such as installation layout. I see. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] Re: Sure enough, the lock file is gone
I understand why the socket needs to be in /tmp, but why the lockfile? 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. The location of the socket files is essentially a core part of the frontend-backend protocol, because both client and server must know it ab initio. Move the socket, break your clients. 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 see no real good reason to keep the lockfiles in a different place from the sockets themselves, however. Doing so would just complicate things even more, without adding any real safety or security. regards, tom lane
