[HACKERS] ipv6 build error?
On FreeBSD/Alpha: gmake[3]: Entering directory `/home/chriskl/pgsql-head/src/backend/libpq' gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../.. /src/include -c -o be-fsstubs.o be-fsstubs.c -MMD gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../.. /src/include -c -o be-secure.o be-secure.c -MMD gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../.. /src/include -c -o auth.o auth.c -MMD gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../.. /src/include -c -o crypt.o crypt.c -MMD gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../.. /src/include -c -o hba.o hba.c -MMD gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../.. /src/include -c -o ip.o ip.c -MMD ip.c: In function `convSockAddr6to4': ip.c:368: structure has no member named `s6_addr32' gmake[3]: *** [ip.o] Error 1 gmake[3]: Leaving directory `/home/chriskl/pgsql-head/src/backend/libpq' gmake[2]: *** [libpq-recursive] Error 2 gmake[2]: Leaving directory `/home/chriskl/pgsql-head/src/backend' gmake[1]: *** [install] Error 2 gmake[1]: Leaving directory `/home/chriskl/pgsql-head/src' gmake: *** [install] Error 2 I seem to remember seeing this before when we had some ipv6 code that we decided to remove in the end... Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Threads
Hello all, it's very interesting to see the discussion of "threads" again. I've portet PostgreSQL to a "thread-per-connection" model based on pthreads and it is functional. Most of the work was finding all the static globals in the sourcefiles and swapping them between threads and freeing memory if a thread terminates. (PostgreSQL isn't written very clean in the aspects of memory handling). My version of the thread-based PostgreSQL is not very efficient at the moment because I haven't done any optimisation of the code to better support threads and I'm using just a simple semaphore to control switching of data but this could be a starting point for others who want to see this code. If this direction will be taken seriously I'm very willing to help. If someone is interested in the code I can send a zip file to everyone who wants. Ulrich -- This e-mail is virus scanned Diese e-mail ist virusgeprueft ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Threads
On 6 Jan 2003 at 12:22, Ulrich Neumann wrote: > Hello all, > If someone is interested in the code I can send a zip file to everyone > who wants. I suggest you preserver your work. The reason I suggested thread are mainly two folds. 1) Get I/O time used fuitfully 2) Use multiple CPU better. It will not require as much code cleaning as your efforts might had. However your work will be very useful if somebody decides to use thread in any fashion in core postgresql. I was hoping for bit more optimistic response given that what I suggested was totally optional at any point of time but very important from performance point. Besides the change would have been gradual as required.. Anyway.. Bye Shridhar -- Robot, n.: University administrator. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [webmaster] [HACKERS] New Portal in Place, DNS switched ...
Marc G. Fournier wrote: 'K, but that won't help the mirrors themselves ... what we need to do is pull the users-lounge over to the new VM next ... Do you have access to 64.49.215.8? .9 works for me, but .8 doesn't. :-( Regards and best wishes, Justin Clift ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Threads
On Mon, 2003-01-06 at 05:36, Shridhar Daithankar wrote: > On 6 Jan 2003 at 12:22, Ulrich Neumann wrote: > > > Hello all, > > If someone is interested in the code I can send a zip file to everyone > > who wants. > > I suggest you preserver your work. The reason I suggested thread are mainly two > folds. > > 1) Get I/O time used fuitfully AIO may address this without the need for integrated threading. Arguably, from the long thread that last appeared on the topic of AIO, some hold that AIO doesn't even offer anything beyond the current implementation. As such, it's highly doubtful that integrated threading is going to offer anything beyond what a sound AIO implementation can achieve. > 2) Use multiple CPU better. > Multiple processes tend to universally support multiple CPUs better than does threading. On some platforms, the level of threading support is currently only user mode implementations which means no additional CPU use. Furthermore, some platforms where user-mode threads are defacto, they don't even allow for scheduling bias resulting is less work being accomplished within the same time interval (work slice must be divided between n-threads within the process, all of which run on a single CPU). > It will not require as much code cleaning as your efforts might had. However > your work will be very useful if somebody decides to use thread in any fashion > in core postgresql. > > I was hoping for bit more optimistic response given that what I suggested was > totally optional at any point of time but very important from performance > point. Besides the change would have been gradual as required.. > Speaking for my self, I probably would of been more excited if the offered framework had addressed several issues. The short list is: o Code needs to be more robust. It shouldn't be calling exit directly as, I believe, it should be allowing for PostgreSQL to clean up some. Correct me as needed. I would of also expected the code of adopted PostgreSQL's semantics and mechanisms as needed (error reporting, etc). I do understand it was an initial attempt to simply get something in front of some eyes and have something to talk about. Just the same, I was expecting something that we could actually pull the trigger with. o Code isn't very portable. Looked fairly okay for pthread platforms, however, there is new emphasis on the Win32 platform. I think it would be a mistake to introduce something as significant as threading without addressing Win32 from the get-go. o I would desire a more highly abstracted/portable interface which allows for different threading and synchronization primitives to be used. Current implementation is tightly coupled to pthreads. Furthermore, on platforms such as Solaris, I would hope it would easily allow for plugging in its native threading primitives which are touted to be much more efficient than pthreads on said platform. o Code is not commented. I would hope that adding new code for something as important as threading would be commented. o Code is fairly trivial and does not address other primitives (semaphores, mutexs, conditions, TSS, etc) portably which would be required for anything but the most trivial of threaded work. This is especially true in such an application where data IS the application. As such, you must reasonably assume that threads need some form of portable serialization primitives, not to mention mechanisms for non-trivial communication. o Does not address issues such as thread signaling or status reporting. o Pool interface is rather simplistic. Does not currently support concepts such as wake pool, stop pool, pool status, assigning a pool to work, etc. In fact, it's not altogether obvious what the capabilities intent is of the current pool implementation. o Doesn't seem to address any form of thread communication facilities (mailboxes, queues, etc). There are probably other things that I can find if I spend more than just a couple of minutes looking at the code. Honestly, I love threads but I can see that the current code offering is not much more than a token in its current form. No offense meant. After it's all said and done, I'd have to see a lot more meat before I'd be convinced that threading is ready for PostgreSQL; from both a social and technological perspective. Regards, -- Greg Copeland <[EMAIL PROTECTED]> Copeland Computer Consulting ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] New Portal in Place, DNS switched ...
I'll do it on my site. Marc G. Fournier wrote: Any volunteers to act as a tertiary? :) We're actually working on adding a new server online that is offshore, which will also give us another subnet to work off of ... but having a third-party secondary server wouldn't hurt, you are right ... On Sun, 5 Jan 2003 [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Speaking of DNS, we should probably not put all of our eggs in one basket (subnet): $ whois postgresql.org ... Domain servers in listed order: NS.HUB.ORG 64.49.215.5 NS2.HUB.ORG 64.49.215.6 It would be nice if one or more nameservers were added that were not in the same subnet, especially because we have so many mirrors (subdomains) that are scattered all over the globe. Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200301051008 -BEGIN PGP SIGNATURE- Comment: http://www.turnstep.com/pgp.html iD8DBQE+GE5lvJuQZxSWSsgRAteAAJ9YQF/eOpS+bZl84HOT84HAiaRQtQCfawbI VpEZSB8oXoO3ycza4g6h5Hg= =19gB -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] New Portal in Place, DNS switched ...
The site looks fantastic! Great work! Marc G. Fournier wrote: I'm just announcing here, since I'd like to see some ppl testing this out and let us know if there are any problems ... DNS is going to take a little while to propogate, so the old site may still come up in the interium ... another reason not to announce it right away :) ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Bison 1.875 RPMs
Guys, for your convenience i've put online a source RPM for Bison 1.875 along with binary RPMs for Redhat 7.2, 7.3 and 8.0. Hunting around the net i didn't find any existing Bison >= 1.50 RPMs, so this should be useful for those compiling PostgreSQL (ECPG in particular) from the CVS source: http://services.csl.co.uk/postgresql/bison-1.875-1PGDG.src.rpm http://services.csl.co.uk/postgresql/redhat72/bison-1.875-1PGDG.i386.rpm http://services.csl.co.uk/postgresql/redhat73/bison-1.875-1PGDG.i386.rpm http://services.csl.co.uk/postgresql/redhat80/bison-1.875-1PGDG.i386.rpm The PGDG tag seemed appropriate. >From version 1.50 onward Bison starting installing a 'yacc' script - i've disabled the creation of this in these RPMs so upgrades can be done simply without conflicting with the 'byacc' package (guess this is Bison based too)... Thanks, Lee. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] New Portal in Place, DNS switched ...
Marc G. Fournier wrote: Any volunteers to act as a tertiary? :) We're actually working on adding a new server online that is offshore, which will also give us another subnet to work off of ... but having a third-party secondary server wouldn't hurt, you are right ... OK, add 64.46.156.80 as a slave to your master, and NSC.INSPECTHOUSE.COM will provide DNS services. On Sun, 5 Jan 2003 [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Speaking of DNS, we should probably not put all of our eggs in one basket (subnet): $ whois postgresql.org ... Domain servers in listed order: NS.HUB.ORG 64.49.215.5 NS2.HUB.ORG 64.49.215.6 It would be nice if one or more nameservers were added that were not in the same subnet, especially because we have so many mirrors (subdomains) that are scattered all over the globe. Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200301051008 -BEGIN PGP SIGNATURE- Comment: http://www.turnstep.com/pgp.html iD8DBQE+GE5lvJuQZxSWSsgRAteAAJ9YQF/eOpS+bZl84HOT84HAiaRQtQCfawbI VpEZSB8oXoO3ycza4g6h5Hg= =19gB -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] ipv6 build error?
Interesting.
I see in BSD/OS /usr/include/netinet6/in6.h:
struct in6_addr {
union {
u_int8_t __u6_addr8[16];
u_int16_t __u6_addr16[8];
u_int32_t __u6_addr32[4];
} __u6_addr;/* 128-bit IP6 address */
};
#define s6_addr __u6_addr.__u6_addr8
#define s6_addr8 __u6_addr.__u6_addr8
#define s6_addr16 __u6_addr.__u6_addr16
#define s6_addr32 __u6_addr.__u6_addr32
and of course the line in ip.c that is causing the problem is:
dst->in.sin_addr.s_addr = src->in6.sin6_addr.s6_addr32[3];
Do you see anything like that? Are you using the newest CVS? (I did
make some CVS adjustments for Tom about 10 hours ago.)
We did pull out IPv6 that was part of an SSL patch in the past because
we didn't support IPv6 anyway. This patch does fully support IPv6 so we
are going to have to adjust things so configure and the code properly
detect and deal with all the IPv6 implementations out there.
---
Christopher Kings-Lynne wrote:
> On FreeBSD/Alpha:
>
> gmake[3]: Entering directory `/home/chriskl/pgsql-head/src/backend/libpq'
> gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../..
> /src/include -c -o be-fsstubs.o be-fsstubs.c -MMD
> gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../..
> /src/include -c -o be-secure.o be-secure.c -MMD
> gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../..
> /src/include -c -o auth.o auth.c -MMD
> gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../..
> /src/include -c -o crypt.o crypt.c -MMD
> gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../..
> /src/include -c -o hba.o hba.c -MMD
> gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../..
> /src/include -c -o ip.o ip.c -MMD
> ip.c: In function `convSockAddr6to4':
> ip.c:368: structure has no member named `s6_addr32'
> gmake[3]: *** [ip.o] Error 1
> gmake[3]: Leaving directory `/home/chriskl/pgsql-head/src/backend/libpq'
> gmake[2]: *** [libpq-recursive] Error 2
> gmake[2]: Leaving directory `/home/chriskl/pgsql-head/src/backend'
> gmake[1]: *** [install] Error 2
> gmake[1]: Leaving directory `/home/chriskl/pgsql-head/src'
> gmake: *** [install] Error 2
>
> I seem to remember seeing this before when we had some ipv6 code that we
> decided to remove in the end...
>
> Chris
>
>
> ---(end of broadcast)---
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[HACKERS] PostgreSQL libraries - PThread Support, but not use...
On a slightly related note to the other threads thread [sic] going on... Over the Christmas/New Year break i've been looking into making the PostgreSQL client libraries (in particular libpq and ecpg) thread-safe - that is they can safely be used by a program which itself is using mutliple threads. I'm largely there with ecpg (globals are protected, a sqlca for each thread), but of course it relies on libpq which needs work to share a connection between thrreads. Relying on thread experience from a few years back on Solaris I had assumed I could just use the pthread_* routines in the shared libraries and they would reference the weak symbols in libc, rather than explicitly pull in libpthread. If the application using the library linked to libpthreads then the 'real' thread routines would be activated, single threaded apps wouldn't need link to libpthread... However there seems to be no standard to which pthread_* routines are available as weak symbols in libc (Linux and Solaris differ). So a couple of questions to decide the course of this work: 1. It's looking likely that the libraries will need to link to libpthread, and as a result anything linking to the libraries will need to link to libpthread too. Will this be accepted in a patch? A similar problem has cropt up with the perl integration recently too (i.e. the Perl developers have decided to link in libpthread). 2. Is their any mileage in using an abstraction layer - ACE, npr? A Bit OTT for what i'm doing, but... 3. Am I wasting my time? I think making the PostgreSQL libraries thread-safe/aware is very worthwhile, but a lot of hurdles... Thanks, Lee. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] PostgreSQL libraries - PThread Support, but not use...
Lee Kindness <[EMAIL PROTECTED]> writes: > On a slightly related note to the other threads thread [sic] going > on... Over the Christmas/New Year break i've been looking into making > the PostgreSQL client libraries (in particular libpq and ecpg) > thread-safe - that is they can safely be used by a program which > itself is using mutliple threads. I'm largely there with ecpg (globals > are protected, a sqlca for each thread), but of course it relies on > libpq which needs work to share a connection between thrreads. AFAIK, libpq is thread-safe already, it's just not thread-aware. What you'd presumably want is a wrapper layer that adds a mutex to prevent multiple threads from manipulating a PGconn at the same time. Couldn't this be done without touching libpq at all? > 1. It's looking likely that the libraries will need to link to > libpthread, and as a result anything linking to the libraries will > need to link to libpthread too. Will this be accepted in a patch? If the patch requires pthread and not any other form of thread support, probably not. See nearby threading thread ;-) In general I'd be unhappy with doing anything to libpq that forces non-threaded clients to start depending on libpthread (or other thread libraries). Thus the idea of a wrapper seems more appealing to me. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] PostgreSQL libraries - PThread Support, but not use...
On Mon, Jan 06, 2003 at 11:58:17AM -0500, Tom Lane wrote: > > AFAIK, libpq is thread-safe already, it's just not thread-aware. > What you'd presumably want is a wrapper layer that adds a mutex to > prevent multiple threads from manipulating a PGconn at the same time. > Couldn't this be done without touching libpq at all? In fact it'd probably be better to do it without touching libpq at all, so the application can tune for the level of thread-safety it needs. There's no point in locking a PGresult for every time the application wants to read a field--it'd be unacceptably slow yet some applications may want to do it. But I'm sure this has been discussed in that other threading thread... Having a thread-aware wrapper multiplex a PGconn between multiple client threads using the nonblocking functions probably isn't going to wash either, because nonblocking operation isn't quite the same as fully asynchronous. And even if the backend protocol allows for it, there's no great benefit since the threads would still be waiting on the same socket and the same backend. Better to give each thread its own PGconn and its own file descriptor to block on, if needed. Jeroen ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL libraries - PThread Support, but not use...
Tom Lane writes: > Lee Kindness <[EMAIL PROTECTED]> writes: > > On a slightly related note to the other threads thread [sic] going > > on... Over the Christmas/New Year break i've been looking into making > > the PostgreSQL client libraries (in particular libpq and ecpg) > > thread-safe - that is they can safely be used by a program which > > itself is using mutliple threads. I'm largely there with ecpg (globals > > are protected, a sqlca for each thread), but of course it relies on > > libpq which needs work to share a connection between thrreads. > > AFAIK, libpq is thread-safe already, it's just not thread-aware. > What you'd presumably want is a wrapper layer that adds a mutex to > prevent multiple threads from manipulating a PGconn at the same time. > Couldn't this be done without touching libpq at all? Certainly, it could. I've not fully investigated the current failings of libpq WRT to threading yet. But it's certainly a bit more than I stated above. I don't know where the statement that libpq is thread safe originated from (I see it's on the website). but at a quick glance I believe that krb4, krb5, PQoidStatus(), PQsetClientEncoding(), winsock_strerror() need more though investigation and non-thread-safe fuctions are also being used (at a glance gethostbyname() and strtok()). > > 1. It's looking likely that the libraries will need to link to > > libpthread, and as a result anything linking to the libraries will > > need to link to libpthread too. Will this be accepted in a patch? > If the patch requires pthread and not any other form of thread support, > probably not. See nearby threading thread ;-) > In general I'd be unhappy with doing anything to libpq that forces > non-threaded clients to start depending on libpthread (or other thread > libraries). Thus the idea of a wrapper seems more appealing to me. Okay, but what about ecpg? Thread-local sqlca instances would be a real benefit, guess Michael and Christof are the guys to talk to? I suppose the real problem is the needed baggage with this - the autoconf macros will be a nightmare! Thanks, Lee. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PostgreSQL libraries - PThread Support, but not use...
We have definatly had requests for improved thread-safeness for libpq and ecpg in the past, so whatever you can do would be a help. We say libpq is thread-safe, but specifically mention the non-threadsafe calls in the libpq documentation, or at least we should. We have been making marginal thread-safe improvements over the years. --- Lee Kindness wrote: > Tom Lane writes: > > Lee Kindness <[EMAIL PROTECTED]> writes: > > > On a slightly related note to the other threads thread [sic] going > > > on... Over the Christmas/New Year break i've been looking into making > > > the PostgreSQL client libraries (in particular libpq and ecpg) > > > thread-safe - that is they can safely be used by a program which > > > itself is using mutliple threads. I'm largely there with ecpg (globals > > > are protected, a sqlca for each thread), but of course it relies on > > > libpq which needs work to share a connection between thrreads. > > > > AFAIK, libpq is thread-safe already, it's just not thread-aware. > > What you'd presumably want is a wrapper layer that adds a mutex to > > prevent multiple threads from manipulating a PGconn at the same time. > > Couldn't this be done without touching libpq at all? > > Certainly, it could. I've not fully investigated the current failings > of libpq WRT to threading yet. But it's certainly a bit more than I > stated above. I don't know where the statement that libpq is thread > safe originated from (I see it's on the website). but at a quick > glance I believe that krb4, krb5, PQoidStatus(), > PQsetClientEncoding(), winsock_strerror() need more though > investigation and non-thread-safe fuctions are also being used (at a > glance gethostbyname() and strtok()). > > > > 1. It's looking likely that the libraries will need to link to > > > libpthread, and as a result anything linking to the libraries will > > > need to link to libpthread too. Will this be accepted in a patch? > > If the patch requires pthread and not any other form of thread support, > > probably not. See nearby threading thread ;-) > > In general I'd be unhappy with doing anything to libpq that forces > > non-threaded clients to start depending on libpthread (or other thread > > libraries). Thus the idea of a wrapper seems more appealing to me. > > Okay, but what about ecpg? Thread-local sqlca instances would be a > real benefit, guess Michael and Christof are the guys to talk to? > > I suppose the real problem is the needed baggage with this - the > autoconf macros will be a nightmare! > > Thanks, Lee. > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Upgrading rant.
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Bruce Momjian) wrote: > Is pg_upgrade too hard to run? Is no one really interested in it? As an end-user, I'm very interested in pg_upgrade, but I think it's kind of a chicken and egg problem. Without much of a guarantee that it's fail-safe, I'm not inclined to test it. As kind of a hamstrung DBA, I don't have a lot of time to do mock-upgrading of my postgres installations. I would imagine there are plenty of DBAs in the user community in this position: wanting a good upgrade utility but not having the time/inclination to do testing on what is available. For commercial products, QA is usually internal. One of the slight drawbacks to the free software community is that more of the burden of QA is placed on the at-large community of users. All this being said, if an outline were posted of what steps to take to test pg_upgrade and ensure that everything were working properly, I'd be more inclined to take the plunge. As it is, I'd have to do a fair amount of research on my own to make sure nothing broke. And that is the step I don't have time for. -tfo ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] New Portal in Place, DNS switched ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >> The PHP site shows adds. > > And I just checked ... so does Sourceforge ... Sourceforge is not a good example: they are not a organization of open source people, but a a site owned by a company (OSDN, Inc.) which in turn is owned by another company (VA Software Corporation). I think it is better to compare to sites that are closer in spirit and mission to us. None of these have banner ads: www.apache.org www.perl.org www.sendmail.org (despite the commercial ties) www.gnupg.org www.opensource.org www.gimp.org www.gnome.org If the banner ads (as previously stated) do not bring in much revenue, is there a reason to keep them? Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200301061347 -BEGIN PGP SIGNATURE- Comment: http://www.turnstep.com/pgp.html iD8DBQE+GdDHvJuQZxSWSsgRAhuTAJ9WTsJnBIZfwrgFJ5wPm75OsZ+2twCeLGYX 7n1RRYGFkmRgLQDNEWcQdQo= =RlGt -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Upgrading rant.
Exactly. I've got something that works and is, in fact, the recommended method for upgrading, currently. For me to switch, I'd need something in which the developers were confident enough to recommend. And even to test, I'd need something more than what is available right now. -tfo In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Bruce Momjian) wrote: > I think you are on to something here. Clearly dump/reload works, and > testing pg_upgrade is time-consuming, so people aren't as inclined to > jump into testing. It isn't quite like testing a bugfix or new feature. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] New Portal in Place, DNS switched ...
On 6 Jan 2003 at 18:44, [EMAIL PROTECTED] wrote: > If the banner ads (as previously stated) do not bring in much revenue, > is there a reason to keep them? This has been mentioned more than once AFAIK. It is in "payment" to those who have provided mirror services. -- Dan Langille : http://www.langille.org/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL libraries - PThread Support, but not use...
On Monday 06 January 2003 12:28, Lee Kindness wrote: > Tom Lane writes: > > Lee Kindness <[EMAIL PROTECTED]> writes: > > > are protected, a sqlca for each thread), but of course it relies on > > > libpq which needs work to share a connection between thrreads. > > AFAIK, libpq is thread-safe already, it's just not thread-aware. > > Couldn't this be done without touching libpq at all? > Certainly, it could. I've not fully investigated the current failings > of libpq WRT to threading yet. But it's certainly a bit more than I > stated above. I don't know where the statement that libpq is thread > safe originated from (I see it's on the website). but at a quick > glance I believe that krb4, krb5, PQoidStatus(), > PQsetClientEncoding(), winsock_strerror() need more though > investigation and non-thread-safe fuctions are also being used (at a > glance gethostbyname() and strtok()). Lee, see the AOLserver source code. AOLserver (www.aolserver.com) is a multithreaded dynamic web server that supports pooled database connections. One of the supported databases is PostgreSQL (I maintain the driver, currently). It's dual licensed (AOLserver Public License and GPL). I've not yet seen a problem that could be traced to libpq not being threadsafe. And AOLserver certainly would show a non-threadsafe problem, particularly with sites running OpenACS, which can easily beat the database to death. BTW: thanks for the Bison RPMs. And I believe the PGDG is appropriate as well. :-) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] PostgreSQL libraries - PThread Support, but not use...
Bruce Momjian <[EMAIL PROTECTED]> writes: > We have definatly had requests for improved thread-safeness for libpq > and ecpg in the past, so whatever you can do would be a help. We say > libpq is thread-safe, but specifically mention the non-threadsafe calls > in the libpq documentation, or at least we should. We do: http://www.ca.postgresql.org/users-lounge/docs/7.3/postgres/libpq-threading.html But Lee's point about depending on possibly-unsafe libc routines is a good one. I don't think anyone's gone through the code with an eye to that. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] New Portal in Place, DNS switched ...
Neil Conway wrote: On Sun, 2003-01-05 at 17:15, Dave Page wrote: There were always ads there Yes -- but AFAIK there were in the process of being phased out (furthermore, the old site only had ads on the initial mirror page, whereas they are much more widespread on the new site). they help pay for the boxes. Obviously, but it's VERY unprofessional for us to show ads to users on our website. It goes without saying, but pretty much every other non-trivial OSS project doesn't have ads on their main website. Displaying ads makes us look more like a Geocities site than a legitimate competitor to Oracle/DB2/etc. In fact, there are several groups that provide free hosting for OSS projects, without requiring them to display ads on their webpages (e.g. SourceForge, Savannah, etc.) Cheers, Neil The PHP site shows adds.
Re: [HACKERS] New Portal in Place, DNS switched ...
On Mon, 6 Jan 2003, mlw wrote: > The PHP site shows adds. And I just checked ... so does Sourceforge ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Upgrading rant.
I think you are on to something here. Clearly dump/reload works, and testing pg_upgrade is time-consuming, so people aren't as inclined to jump into testing. It isn't quite like testing a bugfix or new feature. --- Thomas O'Connell wrote: > In article <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] (Bruce Momjian) wrote: > > > Is pg_upgrade too hard to run? Is no one really interested in it? > > As an end-user, I'm very interested in pg_upgrade, but I think it's kind > of a chicken and egg problem. > > Without much of a guarantee that it's fail-safe, I'm not inclined to > test it. As kind of a hamstrung DBA, I don't have a lot of time to do > mock-upgrading of my postgres installations. I would imagine there are > plenty of DBAs in the user community in this position: wanting a good > upgrade utility but not having the time/inclination to do testing on > what is available. > > For commercial products, QA is usually internal. One of the slight > drawbacks to the free software community is that more of the burden of > QA is placed on the at-large community of users. > > All this being said, if an outline were posted of what steps to take to > test pg_upgrade and ensure that everything were working properly, I'd be > more inclined to take the plunge. As it is, I'd have to do a fair amount > of research on my own to make sure nothing broke. And that is the step I > don't have time for. > > -tfo > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] New Portal in Place, DNS switched ...
Marc G. Fournier wrote: I'm just announcing here, since I'd like to see some ppl testing this out and let us know if there are any problems ... DNS is going to take a little while to propogate, so the old site may still come up in the interium ... another reason not to announce it right away :) My hope was that this would be all the information in a single, integrated site. What I see now is one (nice) front page with links to all the other sites, which don't even have links back, much less the same look and feel. Are you intending to switch those eventually? (Please say yes.) Thanks, Scott ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] SQL_SIZING view
The information schema is supposed to contain a view SQL_SIZING which is defined thus: List the sizing items defined in this standard and, for each of these, indicate the size supported by the SQL-implementation. But the standard does not define any "sizing item" or anything like that anywhere. Unless someone can offer an explanation, I am inclined to just supply an empty table and check off this item. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] I feel the need for speed. What am I doing wrong?
I have a query using two postgres tables.
One is called "CNX_DS_53_SIS_STU_OPT_FEE_TB" and the other is called
"CNX_DS2_53_SIS_STU_OPT_FEE_TB".
I am getting 3 times slower performance than Microsoft Access when
performing a left outer join.
Here are the tables in question:
connxdatasync=# \d "CNX_DS_53_SIS_STU_OPT_FEE_TB"
Table "CNX_DS_53_SIS_STU_OPT_FEE_TB"
Attribute| Type | Modifier
+---+--
RT_REC_KEY | character(14) |
cnxarraycolumn | integer |
CRC| bigint| not null
connxdatasync=# \d "CNX_DS2_53_SIS_STU_OPT_FEE_TB"
Table "CNX_DS2_53_SIS_STU_OPT_FEE_TB"
Attribute| Type | Modifier
+---+--
RT_REC_KEY | character(14) |
cnxarraycolumn | integer |
CRC| bigint| not null
Here is the query:
select a."RT_REC_KEY", a."cnxarraycolumn", a."CRC" from
"CNX_DS_53_SIS_STU_OPT_FEE_TB" a left outer join
"CNX_DS2_53_SIS_STU_OPT_FEE_TB" b on ( a."RT_REC_KEY" = b."RT_REC_KEY"
and a."cnxarraycolumn" = b."cnxarraycolumn") where b.oid is null ;
Creating the following index had no effect on performance!
create unique index i1 on "CNX_DS2_53_SIS_STU_OPT_FEE_TB" ("RT_REC_KEY",
"cnxarraycolumn", "CRC");
Both tables had 6139062 rows of data.
In this query ... all rows of data match perfectly, so no results are
returned.
Is there a way to reformulate this query so that it will use the index?
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] New Portal in Place, DNS switched ...
On Mon, 6 Jan 2003, Scott Lamb wrote: > Marc G. Fournier wrote: > > I'm just announcing here, since I'd like to see some ppl testing this out > > and let us know if there are any problems ... DNS is going to take a > > little while to propogate, so the old site may still come up in the > > interium ... another reason not to announce it right away :) > > My hope was that this would be all the information in a single, > integrated site. What I see now is one (nice) front page with links to > all the other sites, which don't even have links back, much less the > same look and feel. Are you intending to switch those eventually? > (Please say yes.) Yes, the first phase was to get the front-end fixed ... one of Vince's major complaints concerning the old one was that it was near impossible to make changes to it (ie. add menu links) ... ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] OS/400 support?
Hi everyone, We don't support OS/400 yet do we? :-) Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] I feel the need for speed. What am I doing wrong?
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> Creating the following index had no effect on performance!
> create unique index i1 on "CNX_DS2_53_SIS_STU_OPT_FEE_TB" ("RT_REC_KEY",
> "cnxarraycolumn", "CRC");
What does EXPLAIN ANALYZE have to say about the query? If you set
enable_seqscan = 0, does the explain result change?
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] OS/400 support?
Justin Clift <[EMAIL PROTECTED]> writes: > We don't support OS/400 yet do we? Never heard of it. Is it Unix-y? Do you have one available for testing? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] New Portal in Place, DNS switched ...
Marc G. Fournier writes: > I'm just announcing here, since I'd like to see some ppl testing this out > and let us know if there are any problems ... DNS is going to take a > little while to propogate, so the old site may still come up in the > interium ... another reason not to announce it right away :) http://www.postgresql.org/~petere/ doesn't exist anymore. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] OS/400 support?
> -Original Message- > From: Tom Lane [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 06, 2003 5:27 PM > To: Justin Clift > Cc: [EMAIL PROTECTED] > Subject: Re: [HACKERS] OS/400 support? > > > Justin Clift <[EMAIL PROTECTED]> writes: > > We don't support OS/400 yet do we? > > Never heard of it. Is it Unix-y? Do you have one available > for testing? It's IBM. Not terribly Unix-y. This link may prove helpful: http://www-919.ibm.com/developer/factory/porting/faq_proc.html ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] OS/400 support?
On Mon, 6 Jan 2003, Tom Lane wrote: > Justin Clift <[EMAIL PROTECTED]> writes: > > We don't support OS/400 yet do we? > > Never heard of it. Is it Unix-y? Do you have one available for testing? I think Justin is refering to the AS/400 operating system. I have never heard of Postgres supporting this operating system. Gavin ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] OS/400 support?
Tom Lane wrote: Justin Clift <[EMAIL PROTECTED]> writes: We don't support OS/400 yet do we? Never heard of it. Is it Unix-y? Do you have one available for testing? Oops, should have been clearer. OS/400 is the operating system on the IBM AS/400 series of midrange computers: Info: http://search400.techtarget.com/sDefinition/0,,sid3_gci331973,00.html IBM AS/400 page: http://www-132.ibm.com/content/home/store_IBMPublicUSA/en_US/eServer/iSeries/ Not sure if it's Unix-y or not. Just had the question come through the Advocacy site request form. Will see if anyone else has further info, and then ask the requestor for further details if not. :-) Regards and best wishes, Justin Clift regards, tom lane -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] OS/400 support?
Justin Clift <[EMAIL PROTECTED]> writes: > OS/400 is the operating system on the IBM AS/400 series of midrange > computers: > > Info: > http://search400.techtarget.com/sDefinition/0,,sid3_gci331973,00.html > > IBM AS/400 page: > http://www-132.ibm.com/content/home/store_IBMPublicUSA/en_US/eServer/iSeries/ > > Not sure if it's Unix-y or not. Just had the question come through > the Advocacy site request form. Will see if anyone else has further > info, and then ask the requestor for further details if not. AFAIK it's not Unix-y *at* *all*. The best/only way to run PG on that hardware without an immense porting effort would be to run Linux alongside OS/400 in an LPAR (logical partition). -Doug ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] OS/400 support?
Justin Clift <[EMAIL PROTECTED]> writes: > Info: > http://search400.techtarget.com/sDefinition/0,,sid3_gci331973,00.html That page quoth OS/400 and its related software has added support for: The Portable Application Solutions Environment (PASE), which supports a subset of the AIX environment so that Unix applications can be ported and run on the AS/400 This suggests that our AIX port might work with little or no tweaking. Or perhaps not; "subset" could cover a multitude of sins. But it'd be worth trying. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] OS/400 support?
On Mon, 6 Jan 2003, Tom Lane wrote: > Justin Clift <[EMAIL PROTECTED]> writes: > > Info: > > http://search400.techtarget.com/sDefinition/0,,sid3_gci331973,00.html > > That page quoth > > OS/400 and its related software has added support for: > > The Portable Application Solutions Environment (PASE), which > supports a subset of the AIX environment so that Unix applications can > be ported and run on the AS/400 > > This suggests that our AIX port might work with little or no tweaking. > Or perhaps not; "subset" could cover a multitude of sins. But it'd be > worth trying. That would be very wild if we could do that. Who volunteered? ;) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] OS/400 support?
In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (Tom Lane) transmitted: > Justin Clift <[EMAIL PROTECTED]> writes: >> We don't support OS/400 yet do we? > > Never heard of it. Is it Unix-y? Do you have one available for testing? No, OS/400 is what replaced IBM System 34, System 36, and System 38. (Apparently they jumped to 40, and then multiplied by 10 to suggest it was 10x as good...) It was based on the CMU "Hydra" project, which built an OS with a pretty strong security kernel, with ties to the "orthogonal persistence" notion. By this point, they have created a POSIX-emulation environment so it can pretend to be somewhat like a Unix, but underneath, it's a database system for running RPG code. As such, it kind of starts as a DBMS. Somehow, I'm not sure that PostgreSQL-on-OS/400 is likely to be more than a curiosity. -- (reverse (concatenate 'string "moc.enworbbc@" "enworbbc")) http://www3.sympatico.ca/cbbrowne/rdbms.html If you can't see the bright side of things, polish the dark side... ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] OS/400 support?
On Mon, 6 Jan 2003, Dan Langille wrote: > On Mon, 6 Jan 2003, Tom Lane wrote: > > > Justin Clift <[EMAIL PROTECTED]> writes: > > > Info: > > > http://search400.techtarget.com/sDefinition/0,,sid3_gci331973,00.html > > > > That page quoth > > > > OS/400 and its related software has added support for: > > > > The Portable Application Solutions Environment (PASE), which > > supports a subset of the AIX environment so that Unix applications can > > be ported and run on the AS/400 > > > > This suggests that our AIX port might work with little or no tweaking. > > Or perhaps not; "subset" could cover a multitude of sins. But it'd be > > worth trying. > > That would be very wild if we could do that. Who volunteered? ;) It might be pretty simple given PASE support and a hardware/OS manual. The problem is that first assumption: how many OS/400 users have PASE implemented? I'd say, not many. Gavin ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Thank-you to Cybertec Geschwinde & Schonig
Hi, I just got my Christmas thank-you from Austria! It is by far the coolest letter I have ever received. Have the other contributors got them as well? Thanks you guys, Chris Kings-Lynne ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] OS/400 support?
Gavin Sherry <[EMAIL PROTECTED]> writes: > It might be pretty simple given PASE support and a hardware/OS manual. The > problem is that first assumption: how many OS/400 users have PASE > implemented? I'd say, not many. It says here: http://www-919.ibm.com/developer/factory/pase/v5r2.html that PASE is standard as of OS/400 V5R2. Anyone know how old that is? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] OS/400 support?
[EMAIL PROTECTED] writes: > It was based on the CMU "Hydra" project, Really!? Small world ... I was part of the Hydra team, more years ago than I like to admit in public. > Somehow, I'm not sure that PostgreSQL-on-OS/400 is likely to be more > than a curiosity. Probably. But a lot of our ports are just curiosities, at least to them as aren't running that particular OS. My feeling is that Postgres on top of PASE might be reasonable to support; I doubt we'd want to mess with a native port. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] New Portal in Place, DNS switched ...
On Mon, 6 Jan 2003, Peter Eisentraut wrote: > Marc G. Fournier writes: > > > I'm just announcing here, since I'd like to see some ppl testing this out > > and let us know if there are any problems ... DNS is going to take a > > little while to propogate, so the old site may still come up in the > > interium ... another reason not to announce it right away :) > > http://www.postgresql.org/~petere/ doesn't exist anymore. Sounds like someone was messin with httpd.conf. Vince. -- Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/ http://www.meanstreamradio.com http://www.unknown-artists.com Internet radio: It's not file sharing, it's just radio. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] IPv6 patch
Bruce Momjian writes: > Patch applied. I added a small mention of IPv6 addresses to the > pg_hba.conf documentation. Not sure where else to mention it. Can this patch please be cleaned up so the code doesn't contain an #ifdef on every other line? I would also like to discuss how IPv6 is handled during the server start and in pg_hba.conf. It seems that we should treat the address families Unix, IPv4, and IPv6 consistenly, which would mean two things: (1) pg_hba.conf entries pertaining to the address family are allowed and present in the default file, no matter whether the address family is used by the server. (2) A socket type is explicitly enabled for the server to use, and if creation fails, server startup fails. It seems that the current code falls back to IPv4 if IPv6 fails. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] IPv6 patch
On Mon, 2003-01-06 at 15:29, Peter Eisentraut wrote: > (2) A socket type is explicitly enabled for the server to use, and if > creation fails, server startup fails. It seems that the current code > falls back to IPv4 if IPv6 fails. IIRC, it allows it to fall back to IPv4 in case it's compiled for IPv6 support but the kernel isn't compiled to support IPv6. If that is the case, admittedly, you seem to have a point. If someone compiles in v6 support and their system doesn't have v6 support and it's been requested via run-time config, it's should fail just like any other. -- Greg Copeland <[EMAIL PROTECTED]> Copeland Computer Consulting ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] IPv6 patch
Peter Eisentraut wrote: > Bruce Momjian writes: > > > Patch applied. I added a small mention of IPv6 addresses to the > > pg_hba.conf documentation. Not sure where else to mention it. > > Can this patch please be cleaned up so the code doesn't contain an #ifdef > on every other line? I posted the patch a week ago, and mentioned this exact problem. Any suggestions? I realized I could break out the parts into IPv4/6 sections, but then I would have duplicate code paths that were identical except for the IPv4/6 calls. Is that the way to go? The major ugliness is in pqcomm.c and fe-connect.c. Add the unix domain socket and SSL defines, and it is a mess. However, the danger of breaking out the code into separate routines is that then we have to keep them consistent if we make any changes. > I would also like to discuss how IPv6 is handled during the server start > and in pg_hba.conf. It seems that we should treat the address families > Unix, IPv4, and IPv6 consistenly, which would mean two things: > > (1) pg_hba.conf entries pertaining to the address family are allowed and > present in the default file, no matter whether the address family is used > by the server. > > (2) A socket type is explicitly enabled for the server to use, and if > creation fails, server startup fails. It seems that the current code > falls back to IPv4 if IPv6 fails. The issue is that right now, there isn't any special IPv6 enabling, except for lines in pg_hba.conf. I think it is fine to add some enabling, but we then have an additional user interface issue. One idea I had was to change tcpip_socket from true/false to true/false/4/6 so you can specify if you want none(false)/4/6/both(true). The original patch author wants this functionality too, so there clearly is a need for this. This doesn't play nice with the -i flag, however. Also, I need help specifying to listen on _just_ IPv4 or IPv6. The way it is coded, you open IPv6 and IPv4 comes along with it. We could add some test that checks _after_ the connection is made and reject IPv4/6, but it would be better to listen _just_ on the IP version specified. I am not sure how to do that, and the #ipv6 IRC channel wasn't clear either. I tried Google but didn't get a clear answer there either. Also, keep in mine my BSD/OS has libraries to support IPv6, but IPv6 isn't enabled in the kernel, so there is a case where HAVE_IPV6 is true, but when run, opening an IPV6 server fails and I fall back to IPv4 --- just throwing that out as a data point. What would be our default as shipped? I do think we need some user interface control over IPv6 and IPv4. I just coded it to get it working, and compilable on most platforms, and then we can iron out these issues. If we have an IPv6 enablement, it would allow us to keep the pg_hba.conf IPv6 line, and just ignore it, or throw a warning in the logs, though if it is by default in pg_hba.conf, a warning seems strange. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] IPv6 patch
Greg Copeland wrote: > On Mon, 2003-01-06 at 15:29, Peter Eisentraut wrote: > > (2) A socket type is explicitly enabled for the server to use, and if > > creation fails, server startup fails. It seems that the current code > > falls back to IPv4 if IPv6 fails. > > IIRC, it allows it to fall back to IPv4 in case it's compiled for IPv6 > support but the kernel isn't compiled to support IPv6. If that is the > case, admittedly, you seem to have a point. If someone compiles in v6 > support and their system doesn't have v6 support and it's been requested > via run-time config, it's should fail just like any other. Yes, right now, it is kind of a mystery when it falls back to IPv4. It does print a message in the server logs: LOG: server socket failure: getaddrinfo2() using IPv6: hostname nor servname provided, or not known LOG: IPv6 support disabled --- perhaps the kernel does not support IPv6 LOG: IPv4 socket created It appears right at the top because creating the socket is the first thing it does. A good question is once we have a way for the user to control IPv4/6, what do we ship as a default? IPv4-only? Both, and if both, do we fail on a kernel that doesn't have IPv6 enabled? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] New Portal in Place, DNS switched ...
On Mon, 6 Jan 2003, Vince Vielhaber wrote: > On Mon, 6 Jan 2003, Peter Eisentraut wrote: > > > Marc G. Fournier writes: > > > > > I'm just announcing here, since I'd like to see some ppl testing this out > > > and let us know if there are any problems ... DNS is going to take a > > > little while to propogate, so the old site may still come up in the > > > interium ... another reason not to announce it right away :) > > > > http://www.postgresql.org/~petere/ doesn't exist anymore. > > Sounds like someone was messin with httpd.conf. nope, www.postgresql.org is no longer on mars, where the development stuff is located ... I have a way to fix that, just need to find a moment to do so :( ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] IPv6 patch
On Mon, 2003-01-06 at 15:43, Bruce Momjian wrote: > Greg Copeland wrote: > > On Mon, 2003-01-06 at 15:29, Peter Eisentraut wrote: > > > (2) A socket type is explicitly enabled for the server to use, and if > > > creation fails, server startup fails. It seems that the current code > > > falls back to IPv4 if IPv6 fails. > > > > IIRC, it allows it to fall back to IPv4 in case it's compiled for IPv6 > > support but the kernel isn't compiled to support IPv6. If that is the > > case, admittedly, you seem to have a point. If someone compiles in v6 > > support and their system doesn't have v6 support and it's been requested > > via run-time config, it's should fail just like any other. > > Yes, right now, it is kind of a mystery when it falls back to IPv4. It > does print a message in the server logs: > > LOG: server socket failure: getaddrinfo2() using IPv6: hostname nor servname >provided, or not known > LOG: IPv6 support disabled --- perhaps the kernel does not support IPv6 > LOG: IPv4 socket created > > It appears right at the top because creating the socket is the first > thing it does. A good question is once we have a way for the user to > control IPv4/6, what do we ship as a default? IPv4-only? Both, and if > both, do we fail on a kernel that doesn't have IPv6 enabled? So you're saying that by using the IPv6 address family and you bind to an IPv6 address (or even ANY interface), you still get v4 connections on the same bind/listen/accept sequence? I'm asking because I've never done v6 stuff. Regards, -- Greg Copeland <[EMAIL PROTECTED]> Copeland Computer Consulting ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] SQL_SIZING view
Peter Eisentraut wrote: Unless someone can offer an explanation, I am inclined to just supply an empty table and check off this item. I found the definition in FIPS 127-2: http://www.itl.nist.gov/fipspubs/fip127-2.htm The relevant section is section 16.6. Joe ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] SQL_SIZING view
According to: http://www.itl.nist.gov/fipspubs/fip127-2.htm#FIPS_TOP 15.2 SQL_Sizing table. The SQL_SIZING table shall consist of exactly one row for each FIPS SQL database construct defined in Section 16.6 of this standard. The SIZING_ID and DESCRIPTION columns identify the database construct by the integer and description assigned to it in Section 16.6. The ENTRY_VALUE column is equal to the default Entry SQL value defined for that construct by FIPS SQL in Section 16.6, with "*" converted to a Null value. The INTERMEDIATE_VALUE column is equal to the default Intermediate SQL value defined for that construct by FIPS SQL in Section 16.6, with "*" converted to a Null value. The VALUE_SUPPORTED column indicates a value for the construct that is supported by an implementation when data in the identified catalog is accessed through that implementation; if this value is Null, then there is no explicit restriction on the size of that construct. A user must be able to depend upon these values when executing SQL-statements against data in the catalog. If a given catalog spans multiple SQL-Server implementations, then the VALUE_SUPPORTED shall be valid in all of them. It is important to recognize that FIPS sizing defaults are not requirements for conformance to FIPS SQL; instead, they identify a default value that is assumed to be specified if a Federal SQL procurement is silent on that topic. For this reason, the VALUE_SUPPORTED may sometimes be less than the FIPS default for the ENTRY_VALUE or the INTERMEDIATE_VALUE, even for a FIPS SQL conforming implementation. The SIZING_COMMENTS column is intended for any vendor comments pertinent to the identified FIPS SQL database construct. 16.6 Sizing for database constructs. References to this standard in a procurement should indicate minimum requirements for the precision, size, or number of occurrences of database constructs. Failure to make this indication means that the Entry Values detailed below are by default the minimum requirements for Entry SQL or Transitional SQL procurements and the Intermediate Values detailed below are by default the minimum requirements for Intermediate SQL or Full SQL procurements. Sizing EntryInterm. IdDescriptionValueValue 1. Length of an identifier18 128 2 CHARACTER max length 240 1000 3. CHARACTER VARYING max length 254 1000 4. BIT max length in bits * 8000 5. BIT VARYING max length in bits * 8000 6. NATIONAL CHARACTER max length * 500 7. NATIONAL CHAR VARYING max length* 500 8. NUMERIC decimal precision 15 15 9. DECIMAL decimal precision 15 15 10. INTEGER decimal precision 9* 11. INTEGER binary precision* 31 12. SMALLINT decimal precision 4* 13. SMALLINT binary precision * 15 14. FLOAT binary mantissa precision20 47 15. FLOAT binary exponent precision *9 16. REAL binary mantissa precision 20 23 17. REAL binary exponent precision *7 18. DOUBLE PRECISION binary mantissa precision 30 47 19. DOUBLE PRECISION binary exponent precision *9 20. TIME decimal fractional second precision*0 21. TIMESTAMP decimal fractional second precision *6 22. INTERVAL decimal fractional second precision*6 23. INTERVAL decimal leading field precision*7 24. Columns in a table100 250 25. Values in an INSERT statement 100 250 26. Set clauses in UPDATE statement20 250 27. Length of a row (see Note 1) 2000 8000 28. Columns in UNIQUE constraint6 15 29. Length of UNIQUE columns (Note 1) 120 750 30. Columns in GROUP BY column list 6 15 31. Length of GROUP BY column list (Note 1) 120 750 32. Sort items in ORDER BY clause 6 15 33. Length of ORDER BY column list (Note 1) 120 750 34. Referencing columns in FOREIGN KEY 6 15 35. Length of FOREIGN KEY column list (Note 1)120 750 36. Table references in an SQL statement (Note 3) 15 50 37. Cursors simultaneously open10
Re: [HACKERS] IPv6 patch
Greg Copeland wrote: > > It appears right at the top because creating the socket is the first > > thing it does. A good question is once we have a way for the user to > > control IPv4/6, what do we ship as a default? IPv4-only? Both, and if > > both, do we fail on a kernel that doesn't have IPv6 enabled? > > So you're saying that by using the IPv6 address family and you bind to > an IPv6 address (or even ANY interface), you still get v4 connections on > the same bind/listen/accept sequence? > > I'm asking because I've never done v6 stuff. Yes, it listens on both. The original author, Nigel, tested in using both IPv4 and IPv6, and the #ipv6 IRC channel and google postings seem to indicate that too. What I am not sure how to do is say _only_ IPv4. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] IPv6 patch
On Mon, 2003-01-06 at 15:59, Bruce Momjian wrote: > Greg Copeland wrote: > > > It appears right at the top because creating the socket is the first > > > thing it does. A good question is once we have a way for the user to > > > control IPv4/6, what do we ship as a default? IPv4-only? Both, and if > > > both, do we fail on a kernel that doesn't have IPv6 enabled? > > > > So you're saying that by using the IPv6 address family and you bind to > > an IPv6 address (or even ANY interface), you still get v4 connections on > > the same bind/listen/accept sequence? > > > > I'm asking because I've never done v6 stuff. > > Yes, it listens on both. The original author, Nigel, tested in using > both IPv4 and IPv6, and the #ipv6 IRC channel and google postings seem > to indicate that too. What I am not sure how to do is say _only_ IPv4. Wouldn't you just use an IPv4 address family when creating your socket? -- Greg Copeland <[EMAIL PROTECTED]> Copeland Computer Consulting ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] IPv6 patch
Greg Copeland wrote: > On Mon, 2003-01-06 at 15:59, Bruce Momjian wrote: > > Greg Copeland wrote: > > > > It appears right at the top because creating the socket is the first > > > > thing it does. A good question is once we have a way for the user to > > > > control IPv4/6, what do we ship as a default? IPv4-only? Both, and if > > > > both, do we fail on a kernel that doesn't have IPv6 enabled? > > > > > > So you're saying that by using the IPv6 address family and you bind to > > > an IPv6 address (or even ANY interface), you still get v4 connections on > > > the same bind/listen/accept sequence? > > > > > > I'm asking because I've never done v6 stuff. > > > > Yes, it listens on both. The original author, Nigel, tested in using > > both IPv4 and IPv6, and the #ipv6 IRC channel and google postings seem > > to indicate that too. What I am not sure how to do is say _only_ IPv4. > > Wouldn't you just use an IPv4 address family when creating your socket? Sorry, I meant only IPv6. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] IPv6 patch
On Mon, 2003-01-06 at 16:17, Bruce Momjian wrote: > Greg Copeland wrote: > > On Mon, 2003-01-06 at 15:59, Bruce Momjian wrote: > > > Greg Copeland wrote: > > > > > It appears right at the top because creating the socket is the first > > > > > thing it does. A good question is once we have a way for the user to > > > > > control IPv4/6, what do we ship as a default? IPv4-only? Both, and if > > > > > both, do we fail on a kernel that doesn't have IPv6 enabled? > > > > > > > > So you're saying that by using the IPv6 address family and you bind to > > > > an IPv6 address (or even ANY interface), you still get v4 connections on > > > > the same bind/listen/accept sequence? > > > > > > > > I'm asking because I've never done v6 stuff. > > > > > > Yes, it listens on both. The original author, Nigel, tested in using > > > both IPv4 and IPv6, and the #ipv6 IRC channel and google postings seem > > > to indicate that too. What I am not sure how to do is say _only_ IPv4. > > > > Wouldn't you just use an IPv4 address family when creating your socket? > > Sorry, I meant only IPv6. I found this. It seems to imply that you need different sockets to do what you want to do. You might snag a copy of the latest openldap code and look at slapd to see what it's doing. At any rate, here's what I found that pointed me at it: slapd compiled with --enable-ipv6 does only listen to the IPv6 connections. I suspect this is tested on an operating system that receives IPv4 connections to the IPv6 socket as well, although this is not not the case for OpenBSD (nor FreeBSD or NetBSD ,IIRC). slapd needs to listen to both IPv4 and IPv6 on separate sockets. -- Greg Copeland <[EMAIL PROTECTED]> Copeland Computer Consulting ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] IPv6 patch
Greg Copeland wrote: > > > > Yes, it listens on both. The original author, Nigel, tested in using > > > > both IPv4 and IPv6, and the #ipv6 IRC channel and google postings seem > > > > to indicate that too. What I am not sure how to do is say _only_ IPv4. > > > > > > Wouldn't you just use an IPv4 address family when creating your socket? > > > > Sorry, I meant only IPv6. > > > I found this. It seems to imply that you need different sockets to do > what you want to do. You might snag a copy of the latest openldap code > and look at slapd to see what it's doing. > > At any rate, here's what I found that pointed me at it: > > slapd compiled with --enable-ipv6 does only listen to the IPv6 connections. I > suspect this is tested on an operating system that receives IPv4 connections to > the IPv6 socket as well, although this is not not the case for OpenBSD (nor > FreeBSD or NetBSD ,IIRC). slapd needs to listen to both IPv4 and IPv6 on > separate sockets. I wasn't clear on which OS's supported dual ipv4/6 on the same socket. Nigel is testing on Linux, so he says that works for both on the same socket. Maybe on those other OS's we can do separate sockets on the same port number --- not sure. Now that it is in there various OS's can run tests and we will see. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] IPv6 patch
On Mon, 2003-01-06 at 16:40, Bruce Momjian wrote: > Peter Eisentraut wrote: > > Bruce Momjian writes: > The issue is that right now, there isn't any special IPv6 enabling, > except for lines in pg_hba.conf. I think it is fine to add some > enabling, but we then have an additional user interface issue. One idea > I had was to change tcpip_socket from true/false to true/false/4/6 so > you can specify if you want none(false)/4/6/both(true). The original > patch author wants this functionality too, so there clearly is a need > for this. This doesn't play nice with the -i flag, however. > Would there a downside to specifying both (enabling ipv6) on a machine that doesn't support it? If not I'd suggest making -i equivalent to tcp_ip_socket = true. I don't think it's too much to ask people to use the preferred method to obtain maximum functionality. > Also, keep in mine my BSD/OS has libraries to support IPv6, but IPv6 > isn't enabled in the kernel, so there is a case where HAVE_IPV6 is true, > but when run, opening an IPV6 server fails and I fall back to IPv4 --- > just throwing that out as a data point. What would be our default as > shipped? If there is no downside to allowing both, probably both. If there is a downside then ipv4, since it much more likely to be the default on OS's for the next release or two. Robert Treat ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] IPv6 detection
Bruce Momjian writes: > The IPv6 patch currently checks for the function getaddrinfo() and the > include file netinet/ip6.h. getaddrinfo() has nothing to do with IPv6, and netinet/ip6.h isn't included anywhere, so why check for it? I believe we would need to check for a combination of getaddrinfo() inet_ntop()/inet_pton() AF_INET6 struct sockaddr_in6 Then again, it might be simpler to make it a configure option (--enable-ipv6) and just assume all those things exist. Over time the interfaces might stabilize. However, even when IPv6 support is compiled in, we still need some run-time control about whether it should get activated because the presence of the programming interfaces doesn't tell you anything about whether the run-time environment supports it. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Read-only transactions
I would like to implement read-only transactions following the SQL spec, so we can check off this item on the supported list. According to the list I gathered, the following commands will fail if the transaction is read-only: alter * analyze checkpoint cluster comment create * delete (from non-temporary table) drop * execute (if the prepared statement is one in the list) explain analyze (ditto) grant insert (into non-temporary table) reindex revoke select into truncate update (non-temporary table) vacuum I think it's light-weight and marginally useful. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Read-only transactions
Peter Eisentraut <[EMAIL PROTECTED]> writes: > I would like to implement read-only transactions following the SQL spec, > ... > I think it's light-weight and marginally useful. "Light-weight" would depend on your intended implementation, I suppose. Where are you planning to check this? Also, the fact that you are excluding temp tables seems to suggest that this is a very high-level, abstract notion of read-only-ness; it's certainly got little to do with whether we try to write on the disk. As such it's not clear to me why vacuum and checkpoint are included in the forbidden list. They don't logically change any data. The same might be said of reindex. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] New Portal in Place, DNS switched ...
On Mon, 6 Jan 2003, Marc G. Fournier wrote: > On Mon, 6 Jan 2003, Vince Vielhaber wrote: > > > On Mon, 6 Jan 2003, Peter Eisentraut wrote: > > > > > Marc G. Fournier writes: > > > > > > > I'm just announcing here, since I'd like to see some ppl testing this out > > > > and let us know if there are any problems ... DNS is going to take a > > > > little while to propogate, so the old site may still come up in the > > > > interium ... another reason not to announce it right away :) > > > > > > http://www.postgresql.org/~petere/ doesn't exist anymore. > > > > Sounds like someone was messin with httpd.conf. > > nope, www.postgresql.org is no longer on mars, where the development stuff > is located ... I have a way to fix that, just need to find a moment to do > so :( Doesn't matter where it is if the redirect points to the right place. IIRC Peter's webspace was a redirect. Vince. -- Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/ http://www.meanstreamradio.com http://www.unknown-artists.com Internet radio: It's not file sharing, it's just radio. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] New Portal in Place, DNS switched ...
On Mon, 2003-01-06 at 13:26, Marc G. Fournier wrote: > On Mon, 6 Jan 2003, mlw wrote: > > The PHP site shows adds. Ok -- but the vast majority (say, 95%) of OSS sites don't show ads. > And I just checked ... so does Sourceforge ... Not on project websites, though. In any case, I'd be fine with showing ads if there was a demonstrated need for them (and no reasonable alternatives could be found). However, that doesn't seem to be the case: the argument that ads are a necessary compensation for mirrors is not convincing IMHO, given the huge number of other OSS projects that use mirrors, and the relatively tiny number that show ads as a result. If there's a better reason why we need to show ads, what is it? Cheers, Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] I feel the need for speed. What am I doing wrong?
Added -general list so that the next followup can remove -hackers and everyone
there will have had notice.
On Mon, 6 Jan 2003, Dann Corbit wrote:
>
> I have a query using two postgres tables.
> One is called "CNX_DS_53_SIS_STU_OPT_FEE_TB" and the other is called
> "CNX_DS2_53_SIS_STU_OPT_FEE_TB".
>
> I am getting 3 times slower performance than Microsoft Access when
> performing a left outer join.
>
> ...
>
> Here is the query:
> select a."RT_REC_KEY", a."cnxarraycolumn", a."CRC" from
> "CNX_DS_53_SIS_STU_OPT_FEE_TB" a left outer join
> "CNX_DS2_53_SIS_STU_OPT_FEE_TB" b on ( a."RT_REC_KEY" = b."RT_REC_KEY"
> and a."cnxarraycolumn" = b."cnxarraycolumn") where b.oid is null ;
>
>
> Creating the following index had no effect on performance!
> create unique index i1 on "CNX_DS2_53_SIS_STU_OPT_FEE_TB" ("RT_REC_KEY",
> "cnxarraycolumn", "CRC");
>
> Both tables had 6139062 rows of data.
>
> In this query ... all rows of data match perfectly, so no results are
> returned.
I suspect you get no results because it's unlikely b.oid will be null. Are you
sure the query is how it should be since you seem to be expecting no rows to be
returned and yet your reason for that doesn't match the query as shown. Without
the oid test I'd bet you get a result set of 6139062 rows.
> Is there a way to reformulate this query so that it will use the index?
Given the above comment I'd say no since the entirety of both tables will be
tested to make the result set.
Alternatively, if the query is right try something along the lines of:
SELECT a.blah, a.foo,
FROM a, b
WHERE a.blah = b.blah AND a.foo = b.foo AND b.oid IS NULL
if that doesn't use a query try pushing the null test into a subselect like:
SELECT a.blah, a.foo,
FROM a, (SELECT * FROM b WHERE oid IS NULL) b
WHERE a.blah = b.blah AND a.foo = b.foo
After that let's hope I haven't embarrassed myself.
--
Nigel J. Andrews
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] New Portal in Place, DNS switched ...
On Mon, 6 Jan 2003, Neil Conway wrote: > On Mon, 2003-01-06 at 13:26, Marc G. Fournier wrote: > > On Mon, 6 Jan 2003, mlw wrote: > > > The PHP site shows adds. > > Ok -- but the vast majority (say, 95%) of OSS sites don't show ads. Guess that makes us part of the elite 5% that do, eh? You had me worried for awhile there that we were totally exclusive in this *wipe brow* ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] I feel the need for speed. What am I doing wrong?
> -Original Message-
> From: Nigel J. Andrews [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 06, 2003 4:58 PM
> To: Dann Corbit
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] I feel the need for speed. What am I
> doing wrong?
>
> Added -general list so that the next followup can remove
> -hackers and everyone there will have had notice.
>
>
> On Mon, 6 Jan 2003, Dann Corbit wrote:
> >
> > I have a query using two postgres tables.
> > One is called "CNX_DS_53_SIS_STU_OPT_FEE_TB" and the other is called
> > "CNX_DS2_53_SIS_STU_OPT_FEE_TB".
> >
> > I am getting 3 times slower performance than Microsoft Access when
> > performing a left outer join.
> >
> > ...
> >
> > Here is the query:
> > select a."RT_REC_KEY", a."cnxarraycolumn", a."CRC" from
> > "CNX_DS_53_SIS_STU_OPT_FEE_TB" a left outer join
> > "CNX_DS2_53_SIS_STU_OPT_FEE_TB" b on ( a."RT_REC_KEY" =
> b."RT_REC_KEY"
> > and a."cnxarraycolumn" = b."cnxarraycolumn") where b.oid is null ;
> >
> >
> > Creating the following index had no effect on performance! create
> > unique index i1 on "CNX_DS2_53_SIS_STU_OPT_FEE_TB" ("RT_REC_KEY",
> > "cnxarraycolumn", "CRC");
> >
> > Both tables had 6139062 rows of data.
> >
> > In this query ... all rows of data match perfectly, so no
> results are
> > returned.
>
> I suspect you get no results because it's unlikely b.oid will
> be null. Are you sure the query is how it should be since you
> seem to be expecting no rows to be returned and yet your
> reason for that doesn't match the query as shown. Without the
> oid test I'd bet you get a result set of 6139062 rows.
There are supposed to be no results for this particular query.
The data is unique with only RT_REC_KEY and cnxarraycolumn (I tried
using that as an index also).
The basic gist of it is like this:
I want to know where the keys match (e.g.: RT_REC_KEY + cnxarraycolumn)
but the CRC has changed (which will tell me what data has changed).
This is for a data synchronization system that uses PostgreSQL as a join
engine. I store primary key data together with a 64 bit CRC in data
tables stored in PostgreSQL. In this particular case, there were no
changes but there will be changes at other times.
> > Is there a way to reformulate this query so that it will use the
> > index?
>
> Given the above comment I'd say no since the entirety of both
> tables will be tested to make the result set.
>
> Alternatively, if the query is right try something along the lines of:
>
> SELECT a.blah, a.foo,
> FROM a, b
> WHERE a.blah = b.blah AND a.foo = b.foo AND b.oid IS NULL
OID is never null. I don't think that this query is equivalent. This
Oid is just the standard PostgreSQL Oid, and not some arbitrary field.
> if that doesn't use a query try pushing the null test into a
> subselect like:
>
> SELECT a.blah, a.foo,
> FROM a, (SELECT * FROM b WHERE oid IS NULL) b
> WHERE a.blah = b.blah AND a.foo = b.foo
>
OID is never null. I don't think that this query is equivalent.
> After that let's hope I haven't embarrassed myself.
Probably, I did not explain myself clearly enough.
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] ipv6 build error?
Hi Bruce,
I seem to have this:
struct in6_addr {
union {
u_int8_t __u6_addr8[16];
u_int16_t __u6_addr16[8];
u_int32_t __u6_addr32[4];
} __u6_addr;/* 128-bit IP6 address */
};
#define s6_addr __u6_addr.__u6_addr8
#ifdef _KERNEL /*XXX nonstandard*/
#define s6_addr8 __u6_addr.__u6_addr8
#define s6_addr16 __u6_addr.__u6_addr16
#define s6_addr32 __u6_addr.__u6_addr32
#endif
#define INET6_ADDRSTRLEN46
I've attached the full header file.
ifconfig shows IPv6 addresses on the network interfaces, so I assume I have
ipv6 built. It is a 4.4-stable box with GENERIC kernel. I just rebuilt
from very latest CVS and it still failed.
Chris
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, 7 January 2003 12:01 AM
> To: Christopher Kings-Lynne
> Cc: Hackers
> Subject: Re: [HACKERS] ipv6 build error?
>
>
>
> Interesting.
>
> I see in BSD/OS /usr/include/netinet6/in6.h:
>
> struct in6_addr {
> union {
> u_int8_t __u6_addr8[16];
> u_int16_t __u6_addr16[8];
> u_int32_t __u6_addr32[4];
> } __u6_addr;/* 128-bit IP6 address */
> };
>
> #define s6_addr __u6_addr.__u6_addr8
> #define s6_addr8 __u6_addr.__u6_addr8
> #define s6_addr16 __u6_addr.__u6_addr16
> #define s6_addr32 __u6_addr.__u6_addr32
>
> and of course the line in ip.c that is causing the problem is:
>
> dst->in.sin_addr.s_addr = src->in6.sin6_addr.s6_addr32[3];
>
> Do you see anything like that? Are you using the newest CVS? (I did
> make some CVS adjustments for Tom about 10 hours ago.)
>
> We did pull out IPv6 that was part of an SSL patch in the past because
> we didn't support IPv6 anyway. This patch does fully support IPv6 so we
> are going to have to adjust things so configure and the code properly
> detect and deal with all the IPv6 implementations out there.
>
> --
> -
>
> Christopher Kings-Lynne wrote:
> > On FreeBSD/Alpha:
> >
> > gmake[3]: Entering directory
> `/home/chriskl/pgsql-head/src/backend/libpq'
> > gcc -pipe -O -g -Wall -Wmissing-prototypes
> -Wmissing-declarations -I../../..
> > /src/include -c -o be-fsstubs.o be-fsstubs.c -MMD
> > gcc -pipe -O -g -Wall -Wmissing-prototypes
> -Wmissing-declarations -I../../..
> > /src/include -c -o be-secure.o be-secure.c -MMD
> > gcc -pipe -O -g -Wall -Wmissing-prototypes
> -Wmissing-declarations -I../../..
> > /src/include -c -o auth.o auth.c -MMD
> > gcc -pipe -O -g -Wall -Wmissing-prototypes
> -Wmissing-declarations -I../../..
> > /src/include -c -o crypt.o crypt.c -MMD
> > gcc -pipe -O -g -Wall -Wmissing-prototypes
> -Wmissing-declarations -I../../..
> > /src/include -c -o hba.o hba.c -MMD
> > gcc -pipe -O -g -Wall -Wmissing-prototypes
> -Wmissing-declarations -I../../..
> > /src/include -c -o ip.o ip.c -MMD
> > ip.c: In function `convSockAddr6to4':
> > ip.c:368: structure has no member named `s6_addr32'
> > gmake[3]: *** [ip.o] Error 1
> > gmake[3]: Leaving directory `/home/chriskl/pgsql-head/src/backend/libpq'
> > gmake[2]: *** [libpq-recursive] Error 2
> > gmake[2]: Leaving directory `/home/chriskl/pgsql-head/src/backend'
> > gmake[1]: *** [install] Error 2
> > gmake[1]: Leaving directory `/home/chriskl/pgsql-head/src'
> > gmake: *** [install] Error 2
> >
> > I seem to remember seeing this before when we had some ipv6 code that we
> > decided to remove in the end...
> >
> > Chris
> >
> >
> > ---(end of broadcast)---
> > TIP 6: Have you searched our list archives?
> >
> > http://archives.postgresql.org
> >
>
> --
> Bruce Momjian| http://candle.pha.pa.us
> [EMAIL PROTECTED] | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup.| Newtown Square,
> Pennsylvania 19073
>
in6.h
Description: Binary data
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] I feel the need for speed. What am I doing wrong?
"Nigel J. Andrews" <[EMAIL PROTECTED]> writes: >> select a."RT_REC_KEY", a."cnxarraycolumn", a."CRC" from >> "CNX_DS_53_SIS_STU_OPT_FEE_TB" a left outer join >> "CNX_DS2_53_SIS_STU_OPT_FEE_TB" b on ( a."RT_REC_KEY" = b."RT_REC_KEY" >> and a."cnxarraycolumn" = b."cnxarraycolumn") where b.oid is null ; > I suspect you get no results because it's unlikely b.oid will be null. Try "it's impossible for b.oid to be null --- unless a dummy b row is being provided by the LEFT JOIN". I interpret the purpose of the query to be to look for "a" rows that have no matching "b" row. Using OID for this is kind of cute, I guess, since it is guaranteed not-null in a real row; he doesn't have to think about whether any of his regular columns are not-null. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] New Portal in Place, DNS switched ... Banner Adds
I know I participate on this group periodically, but my last position was CTO at a company, and I currently run my own consulting company. I feel I have a pretty neutral perspective. I don't see what the fuss is all about. Banner adds are good, if the PostgreSQL can get some good RELEVANT adds on its site, (a) shows viability, and (b) that there is some sort of revenue. Oracle and Microsoft "rape" their customers, of course they have no 3rd party banner adds, but make no mistake, there are adds for other products by the respective companies. I think that, if you guys want banner adds, it is not a sin, nor is it unprofessional. My only suggestion is to make sure they are relevant to the database market. Adds that are relevant to your core competency enhance your message. Of course, if you post sweepstakes adds, then you blow it. Marc G. Fournier wrote: On Mon, 6 Jan 2003, Neil Conway wrote: On Mon, 2003-01-06 at 13:26, Marc G. Fournier wrote: On Mon, 6 Jan 2003, mlw wrote: The PHP site shows adds. Ok -- but the vast majority (say, 95%) of OSS sites don't show ads. Guess that makes us part of the elite 5% that do, eh? You had me worried for awhile there that we were totally exclusive in this *wipe brow*
Re: [HACKERS] I feel the need for speed. What am I doing wrong?
> -Original Message- > From: Tom Lane [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 06, 2003 5:26 PM > To: Nigel J. Andrews > Cc: Dann Corbit; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: [HACKERS] I feel the need for speed. What am I > doing wrong? > > > "Nigel J. Andrews" <[EMAIL PROTECTED]> writes: > >> select a."RT_REC_KEY", a."cnxarraycolumn", a."CRC" from > >> "CNX_DS_53_SIS_STU_OPT_FEE_TB" a left outer join > >> "CNX_DS2_53_SIS_STU_OPT_FEE_TB" b on ( a."RT_REC_KEY" = > >> b."RT_REC_KEY" and a."cnxarraycolumn" = b."cnxarraycolumn") where > >> b.oid is null ; > > > I suspect you get no results because it's unlikely b.oid > will be null. > > Try "it's impossible for b.oid to be null --- unless a dummy > b row is being provided by the LEFT JOIN". I interpret the > purpose of the query to be to look for "a" rows that have no > matching "b" row. > > Using OID for this is kind of cute, I guess, since it is > guaranteed not-null in a real row; he doesn't have to think > about whether any of his regular columns are not-null. I am very happy to report that PostgreSQL now easily beats MS Access for speed! :-) Here are the MS Access results, where I create on index and then a second: Access Outer Join 2 column index on 1st table 02:29.9 2 column index on 2nd table + 2 column index on 1st table 02:18.3 For PostgreSQL, I originally created a 3 column index (because I have also 3 column joins in other places) and got this result: Postgres Outer Join enable_seqscan = 1 3 column Index 1 12:43.9 Showing the plan showed that the indexes were being ignored. Yikes! Five times slower! But then I took Tom's incredibly helpful suggestion to disable the sequential scan: Postgres Outer Join enable_seqscan = 0 3 column Index 0 05:17.5 Changed to a 2 column index: 2 column index 0 04:58.3 Added an index to the second table: 2 column index on 2nd table + 2 column index on 1st table 0 01:53.6 PostgreSQL is now 22% faster than Access (HAPPY DAYS)! For my application, I happen to know that the data will be approximately physically clustered, and that the indexes will always be very near matches for data sets big enough to matter. Benchmarking also showed that adding the 3rd column to the index was counter productive, even when the join criteria was a.f1 = b.f1, a.f2=b.f2, a.f3 = b.f3. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] I feel the need for speed. What am I doing wrong?
"Dann Corbit" <[EMAIL PROTECTED]> writes: > Yikes! Five times slower! But then I took Tom's incredibly helpful > suggestion to disable the sequential scan: Ideally, you shouldn't have to do that. Now that you have the correct indexes in place, could you show us the EXPLAIN ANALYZE output for both cases (enable_seqscan = on and off)? Also, you might try leaving enable_seqscan = on, and seeing how far you have to decrease random_page_cost to get the planner to choose indexscan. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] PostgreSQL and memory usage
Title: Message I have a machine with 4 CPU's and 2 gigabytes of physical ram. I would like to get PostgreSQL to use as much memory as possible. I can't seem to get PostgreSQL to use more than 100 megabytes or so. How can I optimize the use of PostgreSQL to get the maximum throughput in a configuration like that? Are there any memory usage/tuning documents I can read?
Re: [HACKERS] [GENERAL] PostgreSQL and memory usage
"Dann Corbit" <[EMAIL PROTECTED]> writes: > I have a machine with 4 CPU's and 2 gigabytes of physical ram. > I would like to get PostgreSQL to use as much memory as possible. I > can't seem to get PostgreSQL to use more than 100 megabytes or so. You should not assume that more is necessarily better. In many practical situations, it's better to leave the majority of RAM free for kernel disk caching. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] PostgreSQL and memory usage
> -Original Message- > From: Tom Lane [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 06, 2003 7:30 PM > To: Dann Corbit > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [GENERAL] PostgreSQL and memory usage > > > "Dann Corbit" <[EMAIL PROTECTED]> writes: > > I have a machine with 4 CPU's and 2 gigabytes of physical > ram. I would > > like to get PostgreSQL to use as much memory as possible. I can't > > seem to get PostgreSQL to use more than 100 megabytes or so. > > You should not assume that more is necessarily better. > > In many practical situations, it's better to leave the > majority of RAM free for kernel disk caching. In any case, I would like to know what knobs and dials are available to turn and what each of them means. In at least one instance, the whole database should fit into memory. I would think that would be faster than any sort of kernel disk caching. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Have people taken a look at pgdiff yet?
Hi everyone, Just found out that the "pgdiff" utility (the one for comparing two different PostgreSQL database's) was released and uploaded to SourceForge in November: http://sourceforge.net/projects/pgdiff Have people already looked at this? :-) Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Thank-you to Cybertec Geschwinde & Schonig
On Monday 06 January 2003 21:01, Christopher Kings-Lynne wrote: > I just got my Christmas thank-you from Austria! It is by far the coolest > letter I have ever received. Have the other contributors got them as well? Ack! I forgot to send a thankyou to them! Thanks for the reminder. Yes, I got one. It made my day (my day needed made that day.). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] bug in latest Makefile commit
gmake[2]: Entering directory `/home/chriskl/pgsql-head/src/backend' Makefile:145: *** missing separator (did you mean TAB instead of 8 spaces?). Stop. Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] IPv6 detection
Peter Eisentraut wrote: > Bruce Momjian writes: > > > The IPv6 patch currently checks for the function getaddrinfo() and the > > include file netinet/ip6.h. > > getaddrinfo() has nothing to do with IPv6, and netinet/ip6.h isn't > included anywhere, so why check for it? > > I believe we would need to check for a combination of > > getaddrinfo() > inet_ntop()/inet_pton() > AF_INET6 > struct sockaddr_in6 > > Then again, it might be simpler to make it a configure option > (--enable-ipv6) and just assume all those things exist. Over time the > interfaces might stabilize. > > However, even when IPv6 support is compiled in, we still need some > run-time control about whether it should get activated because the > presence of the programming interfaces doesn't tell you anything about > whether the run-time environment supports it. > I changed the check for sockaddr_in6, rather than ip6.h. Let's see how that works. I would like to have this automatic rather than adding yet another configure flag. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] IPv6 patch
OK, what do we ship as a default? --- Nigel Kukard wrote: > Sorry i'm not subscribed to hackers, guess i must get soon! > > > Anyway what i think should happen is follows, if in the configuration file > we specify that it must bind to both ie. tcpip_socket = true, the server > should check if first its compiled to support ipv6 (or skip this if we use > #ifdef's) and secondly bind to what WE tell it to. If we specify TRUE it > must try to bind to both. Ok thats the first case, the second case is if > we specify ipv4, ie. tcpip_socket = 4. This should ONLY bind ipv4, not ipv6 > and if there is no ipv4 support on the box it should fail, not fallback. > And finally the third case, if we specify tcpip_socket = 6, we should > again ONLY bind to ipv6, if there is no ipv6 support compiled, or if we > cannot bind to the specific interface we should fail. > > Thats my opinion ;) > > > -Nigel > > > > On 6 Jan 2003, Robert Treat wrote: > > > On Mon, 2003-01-06 at 16:40, Bruce Momjian wrote: > > > Peter Eisentraut wrote: > > > > Bruce Momjian writes: > > > The issue is that right now, there isn't any special IPv6 enabling, > > > except for lines in pg_hba.conf. I think it is fine to add some > > > enabling, but we then have an additional user interface issue. One idea > > > I had was to change tcpip_socket from true/false to true/false/4/6 so > > > you can specify if you want none(false)/4/6/both(true). The original > > > patch author wants this functionality too, so there clearly is a need > > > for this. This doesn't play nice with the -i flag, however. > > > > > > > Would there a downside to specifying both (enabling ipv6) on a machine > > that doesn't support it? If not I'd suggest making -i equivalent to > > tcp_ip_socket = true. I don't think it's too much to ask people to use > > the preferred method to obtain maximum functionality. > > > > > Also, keep in mine my BSD/OS has libraries to support IPv6, but IPv6 > > > isn't enabled in the kernel, so there is a case where HAVE_IPV6 is true, > > > but when run, opening an IPV6 server fails and I fall back to IPv4 --- > > > just throwing that out as a data point. What would be our default as > > > shipped? > > > > If there is no downside to allowing both, probably both. If there is a > > downside then ipv4, since it much more likely to be the default on OS's > > for the next release or two. > > > > Robert Treat > > > > > > > > > > -- > > > Nigel Kukard (Chief Executive Officer) > Lando Technologies Africa (Pty) Ltd > [EMAIL PROTECTED] www.lando.co.za > Tel: 083 399 5822 Fax: 086 1100036 > Hoheisen Park Bellville, Cape Town > National Internet Service Provider > > > The best language to use is the language that was designed for > what you want to use it for - 1997 > > > = > > Disclaimer > -- > The contents of this message and any attachments are intended > solely for the addressee's use and may be legally privileged and/or > confidential information. This message may not be retained, > distributed, copied or used if you are not he addressee of this > message. If this message was sent to you in error, please notify > the sender immediately by reply e-mail and then destroy the message > and any copies thereof. > > Opinions, conclusions and other information in this message may be > personal to the sender and is not that of Lando Technologies Africa > or any of it's subsideries, associated companies or principals and > is therefore not endorsed by any of the Lando groups of companies. > Due to e-maill communication being insecure, Lando groups of > companies do not guarantee confidentiality, security, accuracy or > performance of the e-mail. Any liability for viruses is excluded > to the fullest extent. > > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
