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
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
In scan.l, there is:
decimal (({digit}*\.{digit}+)|({digit}+\.{digit}*))
real
((({digit}*\.{digit}+)|({digit}+\.{digit}*)|({digit}+))([Ee][-+]?{digit}+))
Could this be simplified as:
decimal (({integer}?\.{integer})|({integer}\.{integer}?))
real ((({decimal})|({integer}))([Ee][-+]?{integer}))
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).
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
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
"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
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
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
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 s
Bruce Momjian wrote:
> Lamar Owen wrote:
> > Bruce Momjian wrote:
> > > No one has suggested a location non-root people can put the socket/lock
> > Since RPM's _must_ be installed by root, that doesn't affect them. The
> The issue we have is that we don't assume root installs. Any root
> requir
Tom Lane wrote:
>Just out of curiosity, does Debian enforce a nonstandard location for
>X sockets as well?
X has a big exception made for it in the FHS for /usr/X11R6; I don't see
any mention of how /tmp/.X11/ is to be treated, but X isn't my problem!
I suspect no-one has ever thought to ask
> 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
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 R
> 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 lik
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/.postgr
> 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? everythin
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
> 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?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED]
Lamar Owen <[EMAIL PROTECTED]> writes:
> Tom fixed the bug with a slight kludge -- by touching the lock
> periodically, the problem is ameliorated for now. But as long as we
> have a persistent file in /tmp we will run into OS-dependent problems.
> I can see now a bug report that PostgreSQL is u
The Hermit Hacker wrote:
> 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 ...
Talk about timing. :-)
RPM's shortly. Either tonight or tomorrow night. No changes to any locks
or
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
> It has touched a nerve, hasn't it? I like your solution -- but, to
> reiterate, this IMHO is 7.2 material, unless we want to go the feature
> patch route, or someone considers this a 'bugfix' (I don't). Unless it
> is a trivial change, that is.
>
> Tom fixed the bug with a slight kludge -- by
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 PROTEC
The Hermit Hacker wrote:
> On Sun, 28 Jan 2001, Tom Lane wrote:
> > "Oliver Elphick" <[EMAIL PROTECTED]> writes:
> > > 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 nonstandar
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
"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 t
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 PG
> 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
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
> > dir
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...
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, ri
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 wid
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
[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 store
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 wh
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, pl
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 sam
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).
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-
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 somethi
[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 o
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 re
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...
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/
Trond Eivind Glomsrød wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > Trond Eivind Glomsrød 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 compati
Lamar Owen wrote:
>Ok, why not fix tmpwatch instead? Only the lock files break FHS -- the
>sockets can go there by FHS, right?
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 trans
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 ca
Lamar Owen <[EMAIL PROTECTED]> writes:
> Trond Eivind Glomsrød 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 compatibil
Trond Eivind Glomsrød 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
> > soc
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 all
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]
[EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes:
> 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
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 sin
54 matches
Mail list logo
