Re: [HACKERS] 7.1beta4 RPMs.

[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 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

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

[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 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

[HACKERS] scan.l simplifications

[Robert B. Easter]

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}))

What is the reason if it shouldn't be?  This is just an educational question, 
I guess. I wouldn't want to waste time writing bad patches. :)  I ran regress 
with this change and it looked ok.

One reason I can think of right now, is that if the definition of integer or 
decimal were to change, it might break decimal and real.  Another reason 
might be a performance loss?

-- 
 Robert B. Easter  [EMAIL PROTECTED] -
-- CompTechNews Message Board http://www.comptechnews.com/ --
-- CompTechServ Tech Services http://www.comptechserv.com/ --
-- http://www.comptechnews.com/~reaster/ 

[HACKERS] 7.1beta4 RPMs.

[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).
-
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

[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 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

[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 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

[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 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 

[HACKERS] Can PyGreSQL be updated?

[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  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]

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

[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 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

[Lamar Owen]

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
> requirement is going to be RPM-specific.

[waiting on another RPM build cycle to finish]

I understand that issue.  The RPMset is just not affected by that issue,
as, for an RPM to be installed, you must be root.  No ifs ands or buts
-- an RPM installation assumes root, and can do anything along those
lines it needs to do.

Of course, that means I have to be extra careful -- people installing
RPM's I build are going to be running my %pre, %post, %preun, and
%postun scripts _as_root_.  RPM's are quite capable of royally hosing a
system, if the packager hasn't done his homework.  But that also means
malicious RPMs are possible (horrors.) -- one header in an RPM, hidden
from view, could render your system totally useless.  Yes, it's true.
No, I won't package an RPM 'bomb' -- but it could be done, easily
enough.

Now, you can _build_ an RPM (which will be installed as root) as a
non-root user, and that invokes the 'make install' as part of its
process, but I digress (badly, at that).

But my issue is that libpq or any other client should be smart enough to
not have to assume the location.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

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

[Oliver Elphick]

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 the question!  You may be
pleased to know that I have now stirred the coals and asked that
question, which applies not only to X but also to several other programs
that I have running.

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
proportion of total PostgreSQL installs they now are.  We are
a long way now from the days when Postgres was a research database with
a poor reputation for reliability.  It is now becoming a serious
competitor to major commercial databases and will in many cases be
used as a major application on the machines where it is installed.

Are there still people who can only install PostgreSQL as a private 
application?


-- 
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

[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 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]

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.

I have no problem with the default being in /tmp, just like I have no
problem with the default source installation being in /usr/local.  But I
do think that the code should be smart enough to handle non-default
settings without major problems.

And I'll kindly not exaggerate the importance -- but I would have seen
reports had the simple fix not been applied.

But I'm not going to spend any more time arguing about it, that much is
certain. I've got other fish to fry, like beta4 RPM's.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

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

[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 /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

[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 /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]

> 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

[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 directory structure ...

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

[Bruce Momjian]

> 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]   |  (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

[Tom Lane]

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 unreliable because it
> keeps crashing every x days

Kindly don't exaggerate the importance of this problem.  We've been
running systems with the socketfiles in /tmp for years now, and we
know quite well what the downsides of that are.  They're not that
drastic (unless you run a tmp-sweeper too stupid to distinguish socket
files from plain files, and even then you only see failure to connect).

Addition of the socket lockfile to the mix isn't increasing the risks
measurably that I can see.  Even if a tmp-sweeper is enthusiastic enough
to remove a lockfile that the postmaster touches every few minutes, so
what?  Client connections don't depend on the lockfile.  The lockfile
only exists to protect against admin error, ie, starting a second
postmaster on the same socket --- which in routine operation won't
happen anyway.

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
compatibility problem to fix it.  Perhaps someday we will switch to
a whole new interface protocol (CORBA or whatever floats your boat),
and then we can let the whole mess drift off into the sunset.  But
right now, there is almost nothing about our FE/BE protocol that
*isn't* a legacy decision --- and fixing it piecemeal at the cost of
a flag day for each fix is not worthwhile.  IMHO anyway.

regards, tom lane

Re: [HACKERS] Beta4 available ...

[Lamar Owen]

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 sockets, either :-).
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

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

[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 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

[Bruce Momjian]

> 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 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 unreliable because it
> keeps crashing every x days (due to a tmpreaper-like program the hapless
> user doesn't know is running in cron).
> 
> Since pg_config already reports what configure options were provided, if
> this is a configure option then the end user can easily find it with
> pg_config, if a static linkage or binary-only custom client that
> directly accesses the fe-be protocol (are there any that we know
> about?).

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.

-- 
  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

[HACKERS] Beta4 available ...

[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 PROTECTED]   secondary: scrappy@{freebsd|postgresql}.org

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

[Lamar Owen]

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 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?

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 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 unreliable because it
keeps crashing every x days (due to a tmpreaper-like program the hapless
user doesn't know is running in cron).

Since pg_config already reports what configure options were provided, if
this is a configure option then the end user can easily find it with
pg_config, if a static linkage or binary-only custom client that
directly accesses the fe-be protocol (are there any that we know
about?).

But we don't need to spend a great deal of time on it, regardless.
Speaking of time to spend, are we a 'go' for beta4 yet?  ETA? (so I can
budget time to rebuild RPM's).
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

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

[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 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

[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 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

[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 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

[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 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

[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."
> > 
> > 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 Glomsrød
Red Hat, Inc.

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

[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 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 Glomsrød
Red Hat, Inc.

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

[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?

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

[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 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]

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

[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 /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]

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

[HACKERS] Development of ISO19100 support in PG

[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, 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]  
Web site: http://www.sopac.org/
 
Support FMaps: 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]

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

[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 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 Glomsrød
Red Hat, Inc.

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

[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 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]

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

[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 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]

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

[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)

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/

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

[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

[Lamar Owen]

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 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

[Oliver Elphick]

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 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.

-- 
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 

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

[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 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 Glomsrød]

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 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 Glomsrød
Red Hat, Inc.

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

[Lamar Owen]

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
> > 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: [GENERAL] MySQL -> Postgres dump converter

[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 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

[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: Sure enough, the lock file is gone

[Tom Lane]

[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 do), this is just a minor change (the files
> are mostly used by bundled tools - any exceptions?)

It is not a minor change.  Pay attention now: moving the socket files
BREAKS THE CLIENT/SERVER PROTOCOL.  Got that?  If you do this, then
no old client program will work against your new server until you
recompile/relink it.

Don't forget, also, that clients built using the standard distribution
won't talk to your server either.  Unless you have *sole* control of
Postgres and Postgres clients on your machine, moving the socket files
is going to create problems.

We have seen enough complaints in the past due to changes in the
protocol (all of which were backwards-compatible, BTW; this isn't)
that I'm pretty hesitant to do another one on such minor grounds as
getting the socket file out of /tmp.

>> 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.

Expect complaints.

I wouldn't be so annoyed at this, if I didn't know very well that the
resulting questions/complaints will come to the Postgres team, and not
to the perpetrator of the incompatibility.  Shall I forward all future
"can't connect to server" bug reports to you to answer?

regards, tom lane

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

[Trond Eivind Glomsrød]

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?)

> 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.

-- 
Trond Eivind Glomsrød
Red Hat, Inc.