Re: [HACKERS] location of Unix socket

2000-11-25 Thread Peter Eisentraut

Bruce Momjian writes:

 Done.  I did not change PQunixsocket or the unixsocket PQconnectdb
 connection option.  Should they be changed too?

They should be removed because PQhost does this now.

-- 
Peter Eisentraut  [EMAIL PROTECTED]   http://yi.org/peter-e/




Re: [HACKERS] SECURITY: psql allows symlink games in /tmp

2000-11-25 Thread Bruce Momjian

 Looks like what I would have done if I knew C.
 
 The only issue remaining is a policy issue as to if psql should call an
 editor in /tmp at all, considering the issues raised bye the recent joe
 vulnerability, ie can we trust the editor not to do a crazy thing, like
 not creating a similarly predictable backup-file name etc.  It should at
 least be documented so that a more parinoid sys-admin can make sure that
 users use a private TMPDIR.

Not sure it is worth the addition.

-- 
  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] OK, that's one LOCALE bug report too many...

2000-11-25 Thread Peter Eisentraut

Lamar Owen writes:

 Yes, I want to ignore their default.

If you want to do that then the infinitely better solution is to compile
without locale support in the first place.  (Make the locale-enabled
server a separate package.)  Alternatively, the locale of the postgres
user to POSIX.

 I can do things in the initscript if necessary.  That only helps the
 RPM's, though, not those from-source RedHat installations.

The subject of this whole discussion was IIRC the "default Red Hat
installation".  Those who compile from source can always make more
informed decisions about what features to enable.

-- 
Peter Eisentraut  [EMAIL PROTECTED]   http://yi.org/peter-e/




Re: [HACKERS] Are pg_control contents really variable-length?

2000-11-25 Thread Vadim Mikheev

 In xlog.c, the declaration of struct ControlFileData says:
 
 /*
  * MORE DATA FOLLOWS AT THE END OF THIS STRUCTURE - locations of data
  * dirs
  */
 
 Is this comment accurate?  I don't see any sign in the code of placing
 extra data after the declared structure.  If you're planning to do it
 in future, I think it would be a bad idea.  I'd prefer to see all the

That was my thought but as you see nothing was done for it, so
feel free to change anything you want there.

Vadim






Re: [HACKERS] psql: anyone ever notice?

2000-11-25 Thread Peter Eisentraut

Vince Vielhaber writes:

 $ psql -U
 psql: option requires an argument -- U
 Try -? for help.
 $ psql -?
 psql: No match.
 $

It advertises '--help' now.  (And yes, '--help' works everywhere.)

-- 
Peter Eisentraut  [EMAIL PROTECTED]   http://yi.org/peter-e/




Re: [HACKERS] OK, that's one LOCALE bug report too many...

2000-11-25 Thread Lamar Owen

Peter Eisentraut wrote:
 Lamar Owen writes:
  Yes, I want to ignore their default.
 
 If you want to do that then the infinitely better solution is to compile
 without locale support in the first place.  (Make the locale-enabled
 server a separate package.)  Alternatively, the locale of the postgres
 user to POSIX.

Ok, let me repeat -- the '--enable-locale' setting will not affect the
collation sequence problem on RedHat.  If you set PostgreSQL to use
locale, it uses it.  If you configure PostgreSQL to not use locale, the
collation set by LANG, LC_ALL, or LC_COLLATE is _STILL_ honored, thanks
to the libc used.

During the 6.5.x cycle, I built, for performance reasons, RPM's without
locale/multibyte support.  These were referred to as the 'nl' RPM's. 
Please see the thread I referred to to see how running with the
'non-locale' RPM's did not in the least solve the problem or change the
symptoms.

Setting the locale environment for the postmaster process is a
possibility, but I'll have to do some testing to see if there are any
interaction problems.  And this still only helps RPM users, as my
initscript is not part of the canonical tarball.
 
  I can do things in the initscript if necessary.  That only helps the
  RPM's, though, not those from-source RedHat installations.
 
 The subject of this whole discussion was IIRC the "default Red Hat
 installation".  Those who compile from source can always make more
 informed decisions about what features to enable.

Those who compile from source and configure for no locale support will
get a nasty surprise on RedHat 6.1 and later.

Even though a different library function is used to do the comparison
for sorts and orderings, libc (in particular, glibc 2.1) _still_ uses
the LC_ALL, LANG, or LC_COLLATE setting to determine collation. For the
--enable-locale case, the function used is  strcoll(); if not,
strncmp(). See varstr_cmp() in src/backend/utils/adt/varlena.c.

IOW, it is advisable to always enable locale on RedHat, as then you can
at least know what to expect.  And you then will still get unexpected
results unless you do some locale work -- and, unfortunately, RedHat
6.x's locale documentation was sketchy at best; nonexistent at worst.  I
haven't seen RedHat 7's printed documentation yet, so I can't comment on
it.

For reference on this issue, please see the archives, in particular the
following messages:
http://www.postgresql.org/mhonarc/pgsql-hackers/1999-12/msg00678.html
http://www.postgresql.org/mhonarc/pgsql-hackers/1999-12/msg00685.html
(where I got the function names above)
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11



Re: [HACKERS] 7.0.2 - 7.0.3 problem

2000-11-25 Thread Tom Lane

"Mitch Vincent" [EMAIL PROTECTED] writes:
 DEBUG:  Data Base System is starting up at Sun Nov 12 18:20:04 2000
 FATAL 2:  Read("/usr/local/pgsql/data/pg_control") failed: 2
 FATAL 2:  Read("/usr/local/pgsql/data/pg_control") failed: 2
 Startup failed - abort

 The only compilation change I made was to increase BLCKSZ to 32k (which has
 been running in a production 7.0.2 environment for quite some time).

This case should now deliver a more reasonable error message in current
sources, ie, something about BLCKSZ mismatch...

regards, tom lane



Re: [HACKERS] OK, that's one LOCALE bug report too many...

2000-11-25 Thread Peter Eisentraut

Lamar Owen writes:

 Ok, let me repeat -- the '--enable-locale' setting will not affect the
 collation sequence problem on RedHat.  If you set PostgreSQL to use
 locale, it uses it.  If you configure PostgreSQL to not use locale, the
 collation set by LANG, LC_ALL, or LC_COLLATE is _STILL_ honored, thanks
 to the libc used.

Well, I'm looking at Red Hat 7.0 here and the locale variables are most
certainly getting ignored in the default compile.  Moreover, at no point
did strncmp() in glibc behave as you claim.  You can look at it yourself
here:

http://subversions.gnu.org/cgi-bin/cvsweb/glibc/sysdeps/generic/strncmp.c

-- 
Peter Eisentraut  [EMAIL PROTECTED]   http://yi.org/peter-e/




Re: [HACKERS] OK, that's one LOCALE bug report too many...

2000-11-25 Thread Tom Lane

Peter Eisentraut [EMAIL PROTECTED] writes:
 Lamar Owen writes:
 Ok, let me repeat -- the '--enable-locale' setting will not affect the
 collation sequence problem on RedHat.  If you set PostgreSQL to use
 locale, it uses it.  If you configure PostgreSQL to not use locale, the
 collation set by LANG, LC_ALL, or LC_COLLATE is _STILL_ honored, thanks
 to the libc used.

 Well, I'm looking at Red Hat 7.0 here and the locale variables are most
 certainly getting ignored in the default compile.  Moreover, at no point
 did strncmp() in glibc behave as you claim.

I'm having a hard time believing Lamar's recollection, also.  I wonder
if there could have been some other factor involved?  One possible line
of thought: a non-locale-enabled compilation, installed to replace a
locale-enabled one, would behave rather inconsistently if run on the
same database used by the locale-enabled version (since indexes will
still be in locale order).  Depending on what tests you did, you might
well think that it was still running locale-enabled.

BTW: as of my commits of an hour ago, the above failure mode is no
longer possible, since a non-locale-enabled Postgres will now refuse to
start up in a database that shows any locale other than 'C' in pg_control.

regards, tom lane



[HACKERS] tcl/FreeBSD 4.2-STABLE, multiple TCL versions installed

2000-11-25 Thread Larry Rosenman

Trying to compile current sources using:

./configure  --prefix=/home/ler/pg-test --enable-syslog \
--with-CXX --with-perl --enable-multibyte --enable-cassert \
--with-openssl --with-tcl \
--with-tclconfig=/usr/local/lib/tcl8.3 \
--with-tkconfig=/usr/local/lib/tk8.3

I get the following death:

gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql/src/interfaces/libpq++'
gmake[3]: Entering directory `/home/ler/pg-dev/pgsql/src/interfaces/libpgtcl'
gmake -C ../../../src/interfaces/libpq all
gmake[4]: Entering directory `/home/ler/pg-dev/pgsql/src/interfaces/libpq'
gmake[4]: Nothing to be done for `all'.
gmake[4]: Leaving directory `/home/ler/pg-dev/pgsql/src/interfaces/libpq'
gcc -pipe -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC  
-I../../../src/include -I../../../src/interfaces/libpq  -c -o pgtcl.o pgtcl.c
In file included from pgtcl.c:19:
libpgtcl.h:19: tcl.h: No such file or directory
In file included from pgtcl.c:20:
pgtclCmds.h:17: tcl.h: No such file or directory
In file included from pgtcl.c:19:
libpgtcl.h:21: syntax error before `*'
libpgtcl.h:22: syntax error before `*'
In file included from pgtcl.c:20:
pgtclCmds.h:35: syntax error before `Tcl_Interp'
pgtclCmds.h:71: syntax error before `cData'
pgtclCmds.h:73: syntax error before `cData'
pgtclCmds.h:75: syntax error before `cData'
pgtclCmds.h:77: syntax error before `cData'
pgtclCmds.h:79: syntax error before `cData'
pgtclCmds.h:81: syntax error before `cData'
pgtclCmds.h:83: syntax error before `cData'
pgtclCmds.h:85: syntax error before `cData'
pgtclCmds.h:87: syntax error before `cData'
pgtclCmds.h:89: syntax error before `cData'
pgtclCmds.h:91: syntax error before `cData'
pgtclCmds.h:93: syntax error before `cData'
pgtclCmds.h:95: syntax error before `cData'
pgtclCmds.h:97: syntax error before `cData'
pgtclCmds.h:99: syntax error before `cData'
pgtclCmds.h:101: syntax error before `cData'
pgtclCmds.h:103: syntax error before `cData'
In file included from pgtcl.c:21:
pgtclId.h:18: syntax error before `*'
pgtclId.h:37: syntax error before `*'
pgtclId.h:39: syntax error before `cData'
pgtclId.h:40: syntax error before `cData'
pgtclId.h:41: syntax error before `cData'
pgtclId.h:42: syntax error before `*'
pgtclId.h:43: syntax error before `*'
pgtclId.h:44: syntax error before `*'
pgtclId.h:45: syntax error before `*'
pgtclId.h:49: syntax error before `clientData'
pgtclId.h:63: syntax error before `Pg_ConnType'
pgtclId.h:63: warning: type defaults to `int' in declaration of `Pg_ConnType'
pgtclId.h:63: warning: data definition has no type or storage class
pgtcl.c:30: syntax error before `*'
pgtcl.c:31: warning: no previous prototype for `Pgtcl_Init'
pgtcl.c: In function `Pgtcl_Init':
pgtcl.c:43: warning: implicit declaration of function `Tcl_CreateCommand'
pgtcl.c:43: `interp' undeclared (first use in this function)
pgtcl.c:43: (Each undeclared identifier is reported only once
pgtcl.c:43: for each function it appears in.)
pgtcl.c:46: `ClientData' undeclared (first use in this function)
pgtcl.c:46: syntax error before `0'
pgtcl.c:51: syntax error before `0'
pgtcl.c:56: syntax error before `0'
pgtcl.c:61: syntax error before `0'
pgtcl.c:66: syntax error before `0'
pgtcl.c:71: syntax error before `0'
pgtcl.c:76: syntax error before `0'
pgtcl.c:81: syntax error before `0'
pgtcl.c:86: syntax error before `0'
pgtcl.c:91: syntax error before `0'
pgtcl.c:96: syntax error before `0'
pgtcl.c:101: syntax error before `0'
pgtcl.c:106: syntax error before `0'
pgtcl.c:111: syntax error before `0'
pgtcl.c:116: syntax error before `0'
pgtcl.c:121: syntax error before `0'
pgtcl.c:126: syntax error before `0'
pgtcl.c:128: warning: implicit declaration of function `Tcl_PkgProvide'
pgtcl.c:130: `TCL_OK' undeclared (first use in this function)
pgtcl.c:131: warning: control reaches end of non-void function
pgtcl.c: At top level:
pgtcl.c:135: syntax error before `*'
pgtcl.c:136: warning: no previous prototype for `Pgtcl_SafeInit'
pgtcl.c: In function `Pgtcl_SafeInit':
pgtcl.c:137: `interp' undeclared (first use in this function)
gmake[3]: *** [pgtcl.o] Error 1
gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql/src/interfaces/libpgtcl'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/home/ler/pg-dev/pgsql/src/interfaces'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql/src'
gmake: *** [all] Error 2

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749



[HACKERS] Re: [GENERAL] Warning: Don't delete those /tmp/.PGSQL.* files

2000-11-25 Thread Larry Rosenman

* Tom Lane [EMAIL PROTECTED] [001125 16:37]:
 "Joel Burton" [EMAIL PROTECTED] writes:
 
 This story does indicate that we need a less fragile interlock against
 starting two postmasters on one database.  I have to admit that it
 hadn't occurred to me that you could break the port-number interlock
 so easily as that :-(.  But obviously you can, so we need a different
 way of representing the interlock.  Hackers, any thoughts?
how about a .pid/.port/.???  file in the /data directory, and a lock on that? 


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749



Re: [HACKERS] Re: [GENERAL] Warning: Don't delete those /tmp/.PGSQL.*files

2000-11-25 Thread Peter Eisentraut

Tom Lane writes:

 There is a related issue on my todo list, though --- didn't we find out
 awhile back that some older Linux kernels crash and burn if one attempts
 to get an advisory lock on a socket file?  (See thread 7/6/00)  Were we
 going to fix that, and if so how?  Or will we just tell people that they
 have to update their kernel to run Postgres?  The current configure
 script "works around" this by disabling the advisory lock on *all*
 versions of Linux, which I regard as a completely unacceptable
 solution...

Firstly, AFAIK there's no official production kernel that fixes this.  
When and if it gets fixed we can change that logic.

I have simple test program that exhibits the problem (taken from the
kernel mailing list), but

a) You shouldn't run test programs in configure.

b) You really shouldn't run test programs in configure that set up
   networking connections.

c) You definitely shouldn't run test programs in configure that provoke
   kernel exceptions.

We could use flock() on Linux, though.


Maybe we could name the socket file .s.PGSQL.port.pid and make
.s.PGSQL.port a symlink.  Then you can find out whether the postmaster
that created the file is still running.  (You could even put the actual
socket file into the data directory, although that would require
re-thinking the file permissions on the latter.)

Actually, this turns out to be similar to what you wrote in
http://www.postgresql.org/mhonarc/pgsql-hackers/1998-08/msg00835.html


But we really should be fixing the IPC interlock with IPC_EXCL, but the
code changes look to be non-trivial.

-- 
Peter Eisentraut  [EMAIL PROTECTED]   http://yi.org/peter-e/




Re: [HACKERS] tcl/FreeBSD 4.2-STABLE, multiple TCL versions installed

2000-11-25 Thread Peter Eisentraut

Larry Rosenman writes:

   libpgtcl.h:19: tcl.h: No such file or directory
  
  How do you suggest going about finding the tcl.h file?
 it's in /usr/local/include/tcl8.3/ ... 
 
 This will be a problem with TCL as installed by FreeBSD PORTS... 
 
 (maybe configure ought to look for it,  or have a --with-tclinclude=?

I was hoping for a way to let Tcl tell us.  The info is certainly there
somewhere (in tclConfig.sh most likely).

-- 
Peter Eisentraut  [EMAIL PROTECTED]   http://yi.org/peter-e/




[HACKERS] Re: [NOVICE] Re: re : PHP and persistent connections

2000-11-25 Thread Ron Chmara

Note: CC'd to Hackers, as this has wandered into deeper feature issues.

Tom Lane wrote:
 GH [EMAIL PROTECTED] writes:
  Do the "persistent-connected" Postgres backends ever timeout or die?
 No.  A backend will sit patiently for the client to send it another
 query or close the connection.

This does have an unfortunate denial-of-service implication, where
an attack can effectively suck up all available backends, and there's
no throttle, no timeout, no way of automatically dropping these

However, the more likely possibility is similar to the problem that
we see in PHP's persistant connections a normally benign connection
is inactive, and yet it isn't dropped. If you have two of these created
every day, and you only have 16 backends, after 8 days you have a lockout.

On a busy web site or another busy application, you can, of course,
exhaust 64 backends in a matter of minutes.

  Is it possible to set something like a timeout for persistent connctions?
  (Er, would that be something that someone would want
to do? A Bad Thing?)
 This has been suggested before, but I don't think any of the core
 developers consider it a good idea.  Having the backend arbitrarily
 disconnect on an active client would be a Bad Thing for sure.

Right but I don't think anybody has suggested disconnecting an *active*
client, just inactive ones.

 Hence,
 any workable timeout would have to be quite large (order of an
 hour, maybe? not milliseconds anyway). 

The mySQL disconnect starts at around 24 hours. It prevents a slow
accumulation of unused backends, but does nothing for a rapid
accumulation. It can be cranked down to a few minutes AFAIK.

 And that means that it's not
 an effective solution for the problem.  Under load, a webserver that
 wastes backend connections will run out of available backends long
 before a safe timeout would start to clean up after it.

Depends on how it's set up... you see, this isn't uncharted territory,
other web/db solutions have already fought with this issue. Much
like the number of backends set up for pgsql must be static, a timeout
may wind up being the same way. The critical thing to realize is
that you are timing out _inactive_ connections, not connections
in general. So provided that a connection provided information
about when it was last used, or usage set a counter somewhere, it
could easily be checked.

 To my mind, a client app that wants to use persistent connections
 has got to implement some form of connection pooling, so that it
 recycles idle connections back to a "pool" for allocation to task
 threads that want to make a new query.  And the threads have to release
 connections back to the pool as soon as they're done with a transaction.
 Actively releasing an idle connection is essential, rather than
 depending on a timeout.
 
 I haven't studied PHP at all, but from this conversation I gather that
 it's only halfway there...

Well.. This is exactly how apache and PHP serve pages. The
problem is that apache children aren't threads, they are separate copies
of the application itself. So a single apache thread will re-use the
same connection, over and over again, and give that conection over to
other connections on that apache thread.. so in your above model, it's
not really one client application in the first place.

It's a dynamic number of client applications, between one and hundreds
or so.

So to turn the feature request the other way 'round:
"I have all sorts of client apps, connecting in different ways, to
my server. Some of the clients are leaving their connections open,
but unused. How can I prevent running out of backends, and boot
the inactive users off?"

-Ronabop

--
Brought to you from iBop the iMac, a MacOS, Win95, Win98, LinuxPPC machine,
which is currently in MacOS land.  Your bopping may vary.



Re: [HACKERS] tcl/FreeBSD 4.2-STABLE, multiple TCL versions installed

2000-11-25 Thread Larry Rosenman

* Peter Eisentraut [EMAIL PROTECTED] [001125 18:26]:
 Larry Rosenman writes:
 
libpgtcl.h:19: tcl.h: No such file or directory
   
   How do you suggest going about finding the tcl.h file?
  it's in /usr/local/include/tcl8.3/ ... 
  
  This will be a problem with TCL as installed by FreeBSD PORTS... 
  
  (maybe configure ought to look for it,  or have a --with-tclinclude=?
 
 I was hoping for a way to let Tcl tell us.  The info is certainly there
 somewhere (in tclConfig.sh most likely).
It's not.  I already looked in it.  I'm not sure what the 
"standard" is on FreeBSD, I do know that they support multiple
versions concurrently on FreeBSD. I'm not sure what the right fix 
for us is.  
Based on the current 7.0.2 port (from Marc...):

CONFIGURE_TCL=  --with-tcl --with-tclconfig="${LOCALBASE}/lib/tcl8.3 ${LOCALBASE 
}/lib/tk8.3"

Works.  This is, umm, messy at best.
 
 -- 
 Peter Eisentraut  [EMAIL PROTECTED]   http://yi.org/peter-e/

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749



Re: [HACKERS] Re: [GENERAL] Warning: Don't delete those /tmp/.PGSQL.* files

2000-11-25 Thread Tom Lane

Peter Eisentraut [EMAIL PROTECTED] writes:
 Maybe we could name the socket file .s.PGSQL.port.pid and make
 .s.PGSQL.port a symlink.  Then you can find out whether the postmaster
 that created the file is still running.

Or just create a lockfile /tmp/.s.PGSQL.port#.lock, ie, same name as
socket file with ".lock" added (containing postmaster's PID).  Then we
could share code with the data-directory-lockfile case.

 Actually, this turns out to be similar to what you wrote in
 http://www.postgresql.org/mhonarc/pgsql-hackers/1998-08/msg00835.html

Well, we've talked before about moving the socket files to someplace
safer than /tmp.  The problem is to find another place that's not
platform-dependent --- else you've got a major configuration headache.

 But we really should be fixing the IPC interlock with IPC_EXCL, but the
 code changes look to be non-trivial.

AFAIR the previous thread, it wasn't that bad, it was just a matter of
someone taking the time to do it.  Maybe I'll have a go at it...

regards, tom lane



Re: [HACKERS] tcl/FreeBSD 4.2-STABLE, multiple TCL versions installed

2000-11-25 Thread Larry Rosenman

* Larry Rosenman [EMAIL PROTECTED] [001125 18:40]:
 * Larry Rosenman [EMAIL PROTECTED] [001125 18:34]:
  CONFIGURE_TCL=  --with-tcl --with-tclconfig="${LOCALBASE}/lib/tcl8.3 ${LOCALBASE 
}/lib/tk8.3"
  
  Works.  This is, umm, messy at best.
 Err, I lied, Marc adds the /usr/local/include/tcl8.3 and tk8.3 dirs to 
 the --with-includes configure option. 
 
 Still messy.
and it breaks now on 7.1devel sources... 


   
   -- 
   Peter Eisentraut  [EMAIL PROTECTED]   http://yi.org/peter-e/
  
  -- 
  Larry Rosenman http://www.lerctr.org/~ler
  Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
  US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
 -- 
 Larry Rosenman http://www.lerctr.org/~ler
 Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
 US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749



Re: [HACKERS] tcl/FreeBSD 4.2-STABLE, multiple TCL versions installed

2000-11-25 Thread Larry Rosenman

* Larry Rosenman [EMAIL PROTECTED] [001125 18:54]:
   Works.  This is, umm, messy at best.
  Err, I lied, Marc adds the /usr/local/include/tcl8.3 and tk8.3 dirs to 
  the --with-includes configure option. 
  
  Still messy.
 and it breaks now on 7.1devel sources... 
Here is what I issued configure with:

./configure  --prefix=/home/ler/pg-test --enable-syslog \
--with-CXX --with-perl --enable-multibyte --enable-cassert \
--with-openssl \
--with-includes="/usr/local/include/tcl8.3 /usr/local/include/tk8.3" \
--with-tcl \
--with-tclconfig=/usr/local/lib/tcl8.3 \
--with-tkconfig=/usr/local/lib/tk8.3

and it still breaks the same way.  The output doesn't show the
--with-includes directive directories ANYWHERE in the make output :-( 

LER


-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749



Re: [HACKERS] Re: [NOVICE] Re: re : PHP and persistent connections

2000-11-25 Thread Alain Toussaint

 "I have all sorts of client apps, connecting in different ways, to
 my server. Some of the clients are leaving their connections open,
 but unused. How can I prevent running out of backends, and boot
 the inactive users off?"

how about having a middle man between apache (or aolserver or any other
clients...) and PosgreSQL ??

that middleman could be configured to have 16 persistant connections,every
clients would deal with the middleman instead of going direct to the
database,this would be an advantage where multiple PostgreSQL server are
used...

240 apache process are running on a box and there's 60 PostgreSQL instance
running on the machine or another machine:

240 apache process -- middleman -- 60 PostgreSQL process

now if there's multiple Database server:

240 apache process -- middleman -- 12 PostgreSQL for each server (5
servers in this case)

in this case,the middleman could be a shared library which the clients
link to..

what do you think about that ??

Alain Toussaint




Re: [HACKERS] Re: [NOVICE] Re: re : PHP and persistent connections

2000-11-25 Thread Don Baccus

At 12:07 AM 11/26/00 -0500, Alain Toussaint wrote:

how about having a middle man between apache (or aolserver or any other
clients...) and PosgreSQL ??

that middleman could be configured to have 16 persistant connections,every
clients would deal with the middleman instead of going direct to the
database,this would be an advantage where multiple PostgreSQL server are
used...

Well, this is sort of what AOLserver does for you without any need for
middlemen.  

Again, reading stuff like this makes me think "ugh!"

This stuff is really pretty easy, it's amazing to me that the Apache/db
world talks about such kludges when they're clearly not necessary.

My first experience running a website (donb.photo.net) was with Apache
on Linux on an old P100 system in 1996 when few folks had personal photo
sites with 1000 photos on them getting thousands of hits a day.  I have
fond memories of those days, and Apache served me (or more properly webserved
my website) well.  This site is largely responsible for my reputation that
lets me freelance nature photography to the national media market pretty
much at will.  Thus my fondness.

But ... for database stuff the release of AOLserver as first Free Beer,
and now Free Speech software has caused me to abandon Apache and suggestions
like the above just make me cringe.

It shouldn't be that hard, folks.



- Don Baccus, Portland OR [EMAIL PROTECTED]
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.



Re: [HACKERS] Re: [NOVICE] Re: re : PHP and persistent connections

2000-11-25 Thread Don Baccus

At 10:00 PM 11/25/00 -0800, Mitch Vincent wrote:
I've tried quite a bit to use persistent connections with PHP (for over
a year) and always the scripts that I try to use them with behave crazy...
The last time I tried there were problems all over the place with PHP,
variables getting overwritten, certain functions just totally breaking
(date() to name one) and so on.. I know I'm not being specific but my point
is that I think there are some other outstanding PHP issues that play into
this problem as the behavior that I've seen isn't directly related to
PostgreSQL but only happens when I use persistent connections.. 

I've heard rumors that PHP isn't thoroughly threadsafe, could this be a
source of your problems?




- Don Baccus, Portland OR [EMAIL PROTECTED]
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.



Re: [HACKERS] Re: [NOVICE] Re: re : PHP and persistent connections

2000-11-25 Thread Mitch Vincent

I'm sure that this, if true, could certainly be the source of the problems
I've seen... I can't comment on if PHP is completely threadsafe, I know that
some of the modules (for lack of a better word) aren't, possible the ClibPDF
library I'm using. I'll check into it.

Thanks!

-Mitch

- Original Message -
From: "Don Baccus" [EMAIL PROTECTED]
To: "Mitch Vincent" [EMAIL PROTECTED]; "PostgreSQL Hackers List"
[EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Saturday, November 25, 2000 9:18 PM
Subject: Re: [HACKERS] Re: [NOVICE] Re: re : PHP and persistent connections


 At 10:00 PM 11/25/00 -0800, Mitch Vincent wrote:
 I've tried quite a bit to use persistent connections with PHP (for
over
 a year) and always the scripts that I try to use them with behave
crazy...
 The last time I tried there were problems all over the place with PHP,
 variables getting overwritten, certain functions just totally breaking
 (date() to name one) and so on.. I know I'm not being specific but my
point
 is that I think there are some other outstanding PHP issues that play
into
 this problem as the behavior that I've seen isn't directly related to
 PostgreSQL but only happens when I use persistent connections..

 I've heard rumors that PHP isn't thoroughly threadsafe, could this be a
 source of your problems?




 - Don Baccus, Portland OR [EMAIL PROTECTED]
   Nature photos, on-line guides, Pacific Northwest
   Rare Bird Alert Service and other goodies at
   http://donb.photo.net.





Re: [HACKERS] Re: [NOVICE] Re: re : PHP and persistent connections

2000-11-25 Thread Alain Toussaint

 Well, this is sort of what AOLserver does for you without any need for
 middlemen.

i agree that AolServer is good karma,i've been reading various docs on
Aolserver since Philip Greenspun talked about it on linuxworld and i'm glad
that there's some java support being coded for it (im my opinion,it's the only
advantage that Apache had over AolServer for me).

 Again, reading stuff like this makes me think "ugh!"

 This stuff is really pretty easy, it's amazing to me that the Apache/db
 world talks about such kludges when they're clearly not necessary.

well...i was using Apache as an example due to it DB model but the stuff i
was talking would work quite well in the case of multiple DB server
hosting differents table and you want to maintain location
independance,here's an example:

you have 7 Database server,5 are online and the other 2 are for
maintenance and/or development purpose,for simplicity,we'll name the
server database1.example.net to
database7.example.net,database4.example.net is currently doing a dump and
database6.example.net is loading the dump from database4,then,you
reconfigure the middleman so it redirect all request from database4 to
database6:

vim /etc/middleman.conf

and then a sighup to the middleman so it reread its config file:

killall -HUP middleman

this would update the middleman's shared lib with the new configuration
info (and BTW,i just extended my idea from a single shared lib to a
daemon/shared lib combo).

now i'm off to get the dog out for a walk and then,take a nap,see ya !!

Alain Toussaint




[GENERAL] Re: [HACKERS] Indexing for geographic objects?

2000-11-25 Thread Tom Lane

Franck Martin [EMAIL PROTECTED] writes:
 I would greatly appreciate if someone could guide me through the
 methodology to build an index for a custom type or point me to some
 readings where the algorithm is explained (web, book, etc...).

The Programmer's Guide chapter "Interfacing Extensions To Indices"
outlines the procedure for making a new datatype indexable.  It
only discusses the case of adding btree support for a new type,
though.  For other index classes such as R-tree there are different
sets of required operators, which are not as well documented but
you can find out by looking at code for the already-supported
datatypes.

 I plan to use 3D geographical objects...

That's a bit hard since we don't have any indexes suitable for 3-D
coordinates --- the existing R-tree type is for 2-D objects.  What's
more it assumes that coordinates are Euclidean, which is probably
not the model you want for geographical coordinates.

In theory you could build a new index type suitable for indexing
3-D points, using the R-tree code as a starting point.  I wouldn't
class it as a project suitable for a newbie however :-(.

Depending on what your needs are, you might be able to get by with
projecting your objects into a flat 2-D coordinate system and using
an R-tree index in that space.  It'd just be approximate but that
might be close enough for index purposes.

regards, tom lane