Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Alessio Bragadini
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

2001-01-28 Thread Max Rudensky
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

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Lamar Owen
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.

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Trond Eivind Glomsrød
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

[HACKERS] Re: [ADMIN] Controlling user table creation

2001-01-28 Thread Oliver Elphick
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

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Lamar Owen
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

[HACKERS] Re: [ADMIN] Controlling user table creation

2001-01-28 Thread Peter Eisentraut
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

2001-01-28 Thread Peter Eisentraut
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)

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Lamar Owen
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

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Tom Lane
[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

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Tom Lane
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

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Tom Lane
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

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Trond Eivind Glomsrød
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

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Lamar Owen
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

[HACKERS] Development of ISO19100 support in PG

2001-01-28 Thread Franck Martin
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,

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Tom Lane
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

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Tom Lane
[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

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Lamar Owen
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

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Lamar Owen
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

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Lamar Owen
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?

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Trond Eivind Glomsrød
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

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Trond Eivind Glomsrød
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."

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Bruce Momjian
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

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Tom Lane
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

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Tom Lane
"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

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread The Hermit Hacker
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

[HACKERS] Beta4 available ...

2001-01-28 Thread The Hermit Hacker
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

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Tom Lane
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

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread The Hermit Hacker
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

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Bruce Momjian
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

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Tom Lane
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

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Bruce Momjian
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

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Bruce Momjian
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

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Tom Lane
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

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Dominic J. Eidson
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

[HACKERS] Can PyGreSQL be updated?

2001-01-28 Thread Oliver Elphick
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

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Oliver Elphick
"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

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Lamar Owen
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

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Tom Lane
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

[HACKERS] 7.1beta4 RPMs.

2001-01-28 Thread Lamar Owen
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).

Re: [HACKERS] Re: Sure enough, the lock file is gone

2001-01-28 Thread Lamar Owen
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

Re: [HACKERS] 7.1beta4 RPMs.

2001-01-28 Thread Lamar Owen
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