Re: [HACKERS] location of Unix socket
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
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...
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?
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?
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...
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
"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...
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...
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
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
* 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
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
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
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
* 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
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
* 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
* 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
"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
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
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
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
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?
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