Re: [HACKERS] 8.1 Release Candidate 1 Coming ...
On 29/10/05 4:47 am, Marc G. Fournier [EMAIL PROTECTED] wrote: Tomorrow evening, I'm going to wrap up RC1, to announce it on Monday ... if anyone is sitting on *anything*, please say something before about midnight GMT ... Don't include a link for the Windows version in your email please - I'm on a plane most of the day tomorrow, and won't be fit for anything on Monday I doubt, therefore won't get it built. Regards, Dave ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Update for supported platforms list
Hi, All regression tests passed on : * SUSE LINUX 10.0 (i586) OSS * Fedora Core release 4 * Red Hat Linux release 9 * Red Hat Enterprise Linux ES release 3 (Taroon Update 6) Both are x86. Regards, -- Devrim GUNDUZ Kivi Bilişim Teknolojileri - http://www.kivi.com.tr devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 8.1 Release Candidate 1 Coming ...
Marc G. Fournier wrote: Tomorrow evening, I'm going to wrap up RC1, to announce it on Monday ... if anyone is sitting on *anything*, please say something before about midnight GMT ... hmm well -HEAD(and 8.0.4 too!) is broken on AIX 5.3ML3: http://archives.postgresql.org/pgsql-hackers/2005-10/msg01053.php Stefan ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] FKs on temp tables: hard, or just omitted?
You can have foreign keys between temp tables, just not between temp and permanent tables. The latter case is either fairly silly, or technically hard, depending on which direction you have in mind. A temp table referencing a permanent table wouldn't be very silly IMHO... Sander. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] FKs on temp tables: hard, or just omitted?
On Sat, Oct 29, 2005 at 02:54:31PM +0200, Sander Steffann wrote: You can have foreign keys between temp tables, just not between temp and permanent tables. The latter case is either fairly silly, or technically hard, depending on which direction you have in mind. A temp table referencing a permanent table wouldn't be very silly IMHO... Sander. Ok, say someone in another backend deletes a row from the parmanent table, how do they check that no appropriate rows exist in the temp table? A foreign keys involves triggers on both the source and target tables. You solve it by allowing other backends to lock and examine your temporary tables. But AIUI temporary tables are not stored in shared memory so how do you get a consistant view of it? Not unsolvable, but very tricky. Hope this helps, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. pgpNFcb72mXHq.pgp Description: PGP signature
Re: [HACKERS] FKs on temp tables: hard, or just omitted?
-Original Message- From: [EMAIL PROTECTED] on behalf of Sander Steffann Sent: Sat 10/29/2005 1:54 PM To: josh@agliodbs.com; Tom Lane Cc: PostgreSQL-development Subject: Re: [HACKERS] FKs on temp tables: hard, or just omitted? You can have foreign keys between temp tables, just not between temp and permanent tables. The latter case is either fairly silly, or technically hard, depending on which direction you have in mind. A temp table referencing a permanent table wouldn't be very silly IMHO... Err, no, not silly, but difficult. But the other direction would be silly which is what I think Tom meant. Regards, Dave ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.1 Release Candidate 1 Coming ...
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: hmm well -HEAD(and 8.0.4 too!) is broken on AIX 5.3ML3: http://archives.postgresql.org/pgsql-hackers/2005-10/msg01053.php [ shrug... ] The reports of this problem have not given enough information to fix it, and since it's not a regression from 8.0, it's not going to hold up the 8.1 release. When and if we receive enough info to fix it, we'll gladly do so, but ... (My guess is that the problem is a compiler or libc bug anyway, given that one report says that replacing a memcpy call with an equivalent loop makes the failure go away.) regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.1 Release Candidate 1 Coming ...
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: hmm well -HEAD(and 8.0.4 too!) is broken on AIX 5.3ML3: http://archives.postgresql.org/pgsql-hackers/2005-10/msg01053.php [ shrug... ] The reports of this problem have not given enough information to fix it, and since it's not a regression from 8.0, it's not going to hold up the 8.1 release. When and if we receive enough info to fix it, we'll gladly do so, but ... (My guess is that the problem is a compiler or libc bug anyway, given that one report says that replacing a memcpy call with an equivalent loop makes the failure go away.) seneca is using gcc 4.0.1, I can reproduce the sig11 with gcc 3.3.2 and the hang with the IBM AIX-compiler so that would indicate a libc-bug ... If somebody is interested I can provide access to my testbox to help in debugging ... Stefan ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] FKs on temp tables: hard, or just omitted?
Martijn van Oosterhout kleptog@svana.org writes: You solve it by allowing other backends to lock and examine your temporary tables. But AIUI temporary tables are not stored in shared memory so how do you get a consistant view of it? Not unsolvable, but very tricky. Right, the problem isn't that it can't be done, it's that it can't be done without giving up most of the performance advantages of temp tables. Which seems like a bad tradeoff, at least to me ... regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] The argument for reinstating --as-needed
As some of you may remember, a patch for adding --as-needed to the GNU linker command line was added [1] and subsequently removed [2] under the mistaken assumption that it was a linker bug [3]. It isn't. The bug is actually in readline, in that it doesn't declare its dependancy on termcap/ncurses. Note: this bug was fixed back in 2002 in Debian (so no Debian systems are affected by this problem) but is still present in the latest Redhat release and probably many other places. I propose we add a workaround for readline and add the flag back again. The benefits are obvious, from 228 to 87 DT_NEEDED records across a normal PostgreSQL installation, and the server will no longer depend on readline (always an odd point). The patch is attached: it basically adds a reference to termcap/ncurses directly so the psql binary links to it. psql is the only binary that uses readline so this solves the problem. Just a quick note as to why it's not a bug in the linker. The --as-needed flag includes DT_NEEDED records only for libraries referenced by the objects. The issue is that ld removed termcap, needed by readline but not by psql directly. To see why this is not a bug, think about what the -l options are for. They are for resolving symbols not found in the objects you are linking. The linker *does not* look for the symbols needed by the shared libraries given. Static libraries (being sets of objects) yes, shared libraries no. Shared libraries have their own DT_NEEDED records to say what they depend on, they don't need to be checked again. On my Debian system where readline is configured correctly, ncurses is not mentioned on the link line and the linker doesn't look for it either. It is used at runtime though. Other issues: (a) won't this happen again with some other library? Well, unlikely. Obviously this can only affect libraries we list on our link line. Note, a library having this problem would fail autoconf tests also, so we'd know about it. We already have a hack in the autoconf stuff for readline already, I just don't think people expected it to apply to Redhat. (b) it wastes 4 bytes. Well yes, but I think the benefits outweigh the costs. I added it to input.c but it could be a seperate file. (c) an autoconf test to test for this condition. Well, I thought about it but the cost and effort of maintaining such a test is far higher than just forcing the reference. Have a nice day, [1] http://archives.postgresql.org/pgsql-committers/2005-05/msg00042.php [2] http://archives.postgresql.org/pgsql-hackers/2005-05/msg00488.php [3] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157126 -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. Index: input.c === RCS file: /projects/cvsroot/pgsql/src/bin/psql/input.c,v retrieving revision 1.46 diff -u -r1.46 input.c --- input.c 15 Oct 2005 02:49:40 - 1.46 +++ input.c 29 Oct 2005 16:57:48 - @@ -34,6 +34,14 @@ hctl_ignoredups = 2, hctl_ignoreboth = hctl_ignorespace | hctl_ignoredups }; + +/* Work around a bug in some releases of readline. The shared lib doesn't + * doesn't always declare its dependancy on termcap/ncurses/curses. This + * creates a reference to termcap so it gets pulled in, but this is never + * actually used... */ + +extern int tputs(); +int (*__pg_never_used)() = tputs; #endif #ifdef HAVE_ATEXIT pgpHBJCytnxYr.pgp Description: PGP signature
Re: [HACKERS] The argument for reinstating --as-needed
At this stage, I am thinking this is best left for 8.2. It is impossible for us to test it enough. --- Martijn van Oosterhout wrote: -- Start of PGP signed section. As some of you may remember, a patch for adding --as-needed to the GNU linker command line was added [1] and subsequently removed [2] under the mistaken assumption that it was a linker bug [3]. It isn't. The bug is actually in readline, in that it doesn't declare its dependancy on termcap/ncurses. Note: this bug was fixed back in 2002 in Debian (so no Debian systems are affected by this problem) but is still present in the latest Redhat release and probably many other places. I propose we add a workaround for readline and add the flag back again. The benefits are obvious, from 228 to 87 DT_NEEDED records across a normal PostgreSQL installation, and the server will no longer depend on readline (always an odd point). The patch is attached: it basically adds a reference to termcap/ncurses directly so the psql binary links to it. psql is the only binary that uses readline so this solves the problem. Just a quick note as to why it's not a bug in the linker. The --as-needed flag includes DT_NEEDED records only for libraries referenced by the objects. The issue is that ld removed termcap, needed by readline but not by psql directly. To see why this is not a bug, think about what the -l options are for. They are for resolving symbols not found in the objects you are linking. The linker *does not* look for the symbols needed by the shared libraries given. Static libraries (being sets of objects) yes, shared libraries no. Shared libraries have their own DT_NEEDED records to say what they depend on, they don't need to be checked again. On my Debian system where readline is configured correctly, ncurses is not mentioned on the link line and the linker doesn't look for it either. It is used at runtime though. Other issues: (a) won't this happen again with some other library? Well, unlikely. Obviously this can only affect libraries we list on our link line. Note, a library having this problem would fail autoconf tests also, so we'd know about it. We already have a hack in the autoconf stuff for readline already, I just don't think people expected it to apply to Redhat. (b) it wastes 4 bytes. Well yes, but I think the benefits outweigh the costs. I added it to input.c but it could be a seperate file. (c) an autoconf test to test for this condition. Well, I thought about it but the cost and effort of maintaining such a test is far higher than just forcing the reference. Have a nice day, [1] http://archives.postgresql.org/pgsql-committers/2005-05/msg00042.php [2] http://archives.postgresql.org/pgsql-hackers/2005-05/msg00488.php [3] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157126 -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. [ Attachment, skipping... ] -- End of PGP section, PGP failed! -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: 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] The argument for reinstating --as-needed
On Sat, Oct 29, 2005 at 02:47:17PM -0400, Bruce Momjian wrote: At this stage, I am thinking this is best left for 8.2. It is impossible for us to test it enough. I agree. I missed the messages when it went in and missed where it came out. So I looked into it and have found a solution, but like you said, way too late for 8.1. Still maybe a distributor might pick it up since reducing dependancies is fairly important to them. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. pgpOitvyadR0a.pgp Description: PGP signature
Re: [HACKERS] The argument for reinstating --as-needed
Bruce Momjian pgman@candle.pha.pa.us writes: At this stage, I am thinking this is best left for 8.2. It is impossible for us to test it enough. Agreed --- the portability risks are way too high for 8.1. I see no reason not to try it during the 8.2 cycle though. regards, tom lane ---(end of broadcast)--- TIP 1: 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] The argument for reinstating --as-needed
This has been saved for the 8.2 release: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --- Martijn van Oosterhout wrote: -- Start of PGP signed section. As some of you may remember, a patch for adding --as-needed to the GNU linker command line was added [1] and subsequently removed [2] under the mistaken assumption that it was a linker bug [3]. It isn't. The bug is actually in readline, in that it doesn't declare its dependancy on termcap/ncurses. Note: this bug was fixed back in 2002 in Debian (so no Debian systems are affected by this problem) but is still present in the latest Redhat release and probably many other places. I propose we add a workaround for readline and add the flag back again. The benefits are obvious, from 228 to 87 DT_NEEDED records across a normal PostgreSQL installation, and the server will no longer depend on readline (always an odd point). The patch is attached: it basically adds a reference to termcap/ncurses directly so the psql binary links to it. psql is the only binary that uses readline so this solves the problem. Just a quick note as to why it's not a bug in the linker. The --as-needed flag includes DT_NEEDED records only for libraries referenced by the objects. The issue is that ld removed termcap, needed by readline but not by psql directly. To see why this is not a bug, think about what the -l options are for. They are for resolving symbols not found in the objects you are linking. The linker *does not* look for the symbols needed by the shared libraries given. Static libraries (being sets of objects) yes, shared libraries no. Shared libraries have their own DT_NEEDED records to say what they depend on, they don't need to be checked again. On my Debian system where readline is configured correctly, ncurses is not mentioned on the link line and the linker doesn't look for it either. It is used at runtime though. Other issues: (a) won't this happen again with some other library? Well, unlikely. Obviously this can only affect libraries we list on our link line. Note, a library having this problem would fail autoconf tests also, so we'd know about it. We already have a hack in the autoconf stuff for readline already, I just don't think people expected it to apply to Redhat. (b) it wastes 4 bytes. Well yes, but I think the benefits outweigh the costs. I added it to input.c but it could be a seperate file. (c) an autoconf test to test for this condition. Well, I thought about it but the cost and effort of maintaining such a test is far higher than just forcing the reference. Have a nice day, [1] http://archives.postgresql.org/pgsql-committers/2005-05/msg00042.php [2] http://archives.postgresql.org/pgsql-hackers/2005-05/msg00488.php [3] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157126 -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. [ Attachment, skipping... ] -- End of PGP section, PGP failed! -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] TODO Item - Add system view to show free
On Fri, 2005-10-28 at 18:43 +0200, Martijn van Oosterhout wrote: On Fri, Oct 28, 2005 at 05:05:25PM +0100, Simon Riggs wrote: 3. Helping Readahead efficiency: Currently blocks are allocated one at a time. If many tables are extending at the same time, the blocks from multiple tables will be intermixed together on the disk. Reading the data back takes more head movement and reduces the I/O rate. Allocating Ok, I agree with the rest but this isn't true. Any filesystem designed in the last ten years leaves gaps around the place so when you extend a file it remains consecutive. Some filesystems (like XFS) take it to extremes). Interleaving blocks with this pattern hasn't been done since FAT. That isn't to say that preextending isn't a good idea. With my pread() patch it was the one use of lseek() I couldn't remove. Other than that, good thought... Thanks. I wasn't aware of that. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 1: 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] [ADMIN] Fatal error
Peter Ivarsson [EMAIL PROTECTED] writes: FATAL: could not read statistics message: Resource temporarily unavailable What platform is this on exactly, and what version of Postgres? PostgreSQL version 8.0.4 and OS is OsX 10.3 on a Mac G4. I spent some time trying to duplicate this on my own Mac, without success. Has anyone else seen a stats collector failure of this sort? We could certainly tweak the collector code to ignore EAGAIN from recv(), but I'm wondering how it's happening in the first place, seeing that we don't call recv() unless select() says the socket is ready to read. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] 8.1 Release Candidate 1 Bundled ...
Take a look through it, will announce this evening ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
