Re: [HACKERS] A more useful way to split the distribution
On Sun, 08 Apr 2001 11:24, Peter Eisentraut wrote: Since people suddenly seem to be suffering from bandwidth concerns I have devised a new distribution split to address this issue. [ ... snipping the many tarballs argument ... ] For me and I expect many other folk on the edge of civilization it is a total PITA to have to fiddle around and download many separate tarball files. What I want is to be able to start a d/l going and then come back when it's finished and know that I have _everything_ I actually need to have a working and documented product in one shot. For developers, contributors and testers and I would like to suggest that an exact snapshot of the complete CVS source archive is appropriate. We can then track the changes every day using cvs or cvsup - wonderful tool btw - What is really _really_ needed is a text README which explains exactly what file contains. Personally I have found that the limitations of the packaging systems to be such a nuisence that I always compile everything from source. -- Sincerely etc., NAME Christopher Sawtell CELL PHONE 021 257 4451 ICQ UIN45863470 EMAIL csawtell @ xtra . co . nz CNOTES ftp://ftp.funet.fi/pub/languages/C/tutorials/sawtell_C.tar.gz -- Please refrain from using HTML or WORD attachments in e-mails to me -- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] RC3-3 RPMS.
Are up. Contrib subpackage includes built binaries. Binary RPMset built for _Red_Hat_6.2_. I will be building Red Hat 7.0 RPMS after I get back from a two day vacation -- which will put me back online Wednesday. I might get a set out for RH7 tomorrow, though. The split to contrib and docs subpackages has greatly reduced the size of the main client RPM down to a little over 1MB. The contrib subpackage is nearly a meg, as is the docs subpackage (which as yet doesn't have the hardcopy docs). Also, I would love it to see jars of the 7.1 JDBC built in the near future, as I _still_ don't have a good JDK on any of my devel boxen -- meaning I'm still shipping the 7.0 JDBC in the jdbc subpackage. ftp://ftp.postgresql.org/pub/dev/test-rpms,as usual. See README.rpm-dist in the main package for more details, as it is actually up to date at this time. -- 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] RPM upgrade caveats going from a beta version to RC
On Sat, 7 Apr 2001, Lamar Owen wrote: One quick note -- since 'R' 'b', the RC RPM's must be forced to install with --oldpackage, as RPM does a simple strcmp of version numbers -- 7.1RC3 7.1beta1, for instance. Just force it with --oldpackage if you have a 7.1beta RPM already installed. Huh? I always thought that ASCII R was greater then b ... *confused* in the future, would it help to have 7.2Beta? Or am I missing something? :) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] RPM upgrade caveats going from a beta version to RC
The Hermit Hacker wrote: On Sat, 7 Apr 2001, Lamar Owen wrote: One quick note -- since 'R' 'b', the RC RPM's must be forced to install with --oldpackage, as RPM does a simple strcmp of version numbers -- 7.1RC3 7.1beta1, for instance. Just force it with --oldpackage if you have a 7.1beta RPM already installed. Huh? I always thought that ASCII R was greater then b ... *confused* in the future, would it help to have 7.2Beta? Or am I missing something? :) R = 82 b = 98 so b comes after R, and `blank' comes before either! Therefore 7.1 7.1RC 7.1beta ! As I suggested in another mail, let us switch to using even minor numbers for releases and odd ones for development: That means the final release of 7.1 will be called 7.2. Bugfix releases will then be 7.2.x. Meanwhile new development versions will be 7.3.x which will finally be released as 7.4, and so on... For current 7.1, the Debian releases are 7.1beta, 7.1cRC, 7.1final, which is both cumbersome and confusing to those who are looking for an exact match. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "Do not be anxious about anything, but in everything, by prayer and supplication, with thanksgiving, present your requests to God. And the peace of God, which transcends all understanding, will guard your hearts and your minds in Christ Jesus." Philippians 4:6,7 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] RPM upgrade caveats going from a beta version to RC
The Hermit Hacker writes: On Sat, 7 Apr 2001, Lamar Owen wrote: One quick note -- since 'R' 'b', the RC RPM's must be forced to install with --oldpackage, as RPM does a simple strcmp of version numbers -- 7.1RC3 7.1beta1, for instance. Just force it with --oldpackage if you have a 7.1beta RPM already installed. Huh? I always thought that ASCII R was greater then b ... *confused* in the future, would it help to have 7.2Beta? Or am I missing something? :) How about 7.2rc1, which is greater than 7.2beta1. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] A more useful way to split the distribution
Christopher Sawtell writes: For me and I expect many other folk on the edge of civilization it is a total PITA to have to fiddle around and download many separate tarball files. What I want is to be able to start a d/l going and then come back when it's finished and know that I have _everything_ I actually need to have a working and documented product in one shot. Right. The only reason for splitting the distribution is to cater to the fictitious crowd with "bandwidth problems" or those that explicitly know that they don't need the rest. There will still be a canonical full tarball with everything, or at least I will not put my name to something that abolishes it. In fact, I didn't like the idea of the split tarballs in the first place, I'm merely changing the split to something more useful. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] RPM upgrade caveats going from a beta version to RC
On Sun, 8 Apr 2001, Oliver Elphick wrote: The Hermit Hacker wrote: On Sat, 7 Apr 2001, Lamar Owen wrote: One quick note -- since 'R' 'b', the RC RPM's must be forced to install with --oldpackage, as RPM does a simple strcmp of version numbers -- 7.1RC3 7.1beta1, for instance. Just force it with --oldpackage if you have a 7.1beta RPM already installed. Huh? I always thought that ASCII R was greater then b ... *confused* in the future, would it help to have 7.2Beta? Or am I missing something? :) R = 82 b = 98 so b comes after R, and `blank' comes before either! Therefore 7.1 7.1RC 7.1beta ! As I suggested in another mail, let us switch to using even minor numbers for releases and odd ones for development: That means the final release of 7.1 will be called 7.2. Bugfix releases will then be 7.2.x. Meanwhile new development versions will be 7.3.x which will finally be released as 7.4, and so on... Not in this life time ... we are not going to move to a Linux-like development cycle ... *groan* ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Re: A more useful way to split the distribution
I wrote: Since people suddenly seem to be suffering from bandwidth concerns I have devised a new distribution split to address this issue. I propose the following four sub-tarballs: * postgresql-XXX.base.tar.gz 3.3 MB * postgresql-XXX.opt.tar.gz 1.7 MB * postgresql-XXX.docs.tar.gz 1.9 MB * postgresql-XXX.test.tar.gz 1.0 MB Since we're going to make a change, I'd like to change the names to postgresql-base-XXX.tar.gz etc. to align them with existing practice (cf. RPMs, GCC download). Dots should be used for format-identifying extensions. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] RPM upgrade caveats going from a beta version to RC
The Hermit Hacker wrote:or development: That means the final release of 7.1 will be called 7.2. Bugfix releases will then be 7.2.x. Meanwhile new development versions will be 7.3.x which will finally be released as 7.4, and so on... Not in this life time ... we are not going to move to a Linux-like development cycle ... *groan* Harrumph!! Well, pick some scheme that gives a rational set of numbers for distributions. The current one is only good for installation by hand! (Mind you, my other major package is progressing from -1.00 to 0, so that -0.76 is followed by -0.75. Not that I recommend you to follow _that_ example.) -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C "Do not be anxious about anything, but in everything, by prayer and supplication, with thanksgiving, present your requests to God. And the peace of God, which transcends all understanding, will guard your hearts and your minds in Christ Jesus." Philippians 4:6,7 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: RC3 ...
Bruce Momjian writes: I didn't know that. I thought we genarated postscript only major releases. Do we regenerate HTML for subreleases? The HTML is generated every 12 hours, and whenever a distribution is wrapped up it picks up the latest bundle. This will probably have to be sorted out again when a branch is made so the paths are set correctly, but in principle it is trivial to arrange. Not that the documentation ever changes for minor releases. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: A more useful way to split the distribution
On Sun, 8 Apr 2001, Peter Eisentraut wrote: I wrote: Since people suddenly seem to be suffering from bandwidth concerns I have devised a new distribution split to address this issue. I propose the following four sub-tarballs: * postgresql-XXX.base.tar.gz3.3 MB * postgresql-XXX.opt.tar.gz 1.7 MB * postgresql-XXX.docs.tar.gz1.9 MB * postgresql-XXX.test.tar.gz1.0 MB Since we're going to make a change, I'd like to change the names to postgresql-base-XXX.tar.gz etc. to align them with existing practice (cf. RPMs, GCC download). Dots should be used for format-identifying extensions. Go for it ... more a visual change then anything ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RPM upgrade caveats going from a beta version to RC
On Sun, 8 Apr 2001, Oliver Elphick wrote: The Hermit Hacker wrote:or development: That means the final release of 7.1 will be called 7.2. Bugfix releases will then be 7.2.x. Meanwhile new development versions will be 7.3.x which will finally be released as 7.4, and so on... Not in this life time ... we are not going to move to a Linux-like development cycle ... *groan* Harrumph!! Well, pick some scheme that gives a rational set of numbers for distributions. The current one is only good for installation by hand! We do, we follow the scheme as used by ... the BSD camp :) Be thankful we don't go all the way and use 7.2-RELEASE too :) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] A more useful way to split the distribution
this only represents since 8:30am this morning ...
/source/v7.0.3/postgresql-7.0.3.support.tar.gz = 9
/source/v7.0.3/postgresql-7.0.3.test.tar.gz = 3
/source/v7.0.3/postgresql-7.0.3.docs.tar.gz = 10
/source/v7.0.3/postgresql-7.0.3.tar.gz = 22
/source/v7.0.3/postgresql-7.0.3.base.tar.gz = 9
on a side note, we almost have as many downloads of psqlodbc in that time
period:
/odbc/psqlodbc_home.html = 15
/odbc/versions/psqlodbc-07_01_0002.zip = 4
/odbc/versions/psqlodbc-07_01_0003.zip = 4
/odbc/versions/psqlodbc-07_01_0004.zip = 18
so it isn't a "fictitous crowd" that is going with the smaller chunks ...
its about 30% on a very small sample ...
On Sun, 8 Apr 2001, Peter Eisentraut wrote:
Christopher Sawtell writes:
For me and I expect many other folk on the edge of civilization it is a
total PITA to have to fiddle around and download many separate tarball
files. What I want is to be able to start a d/l going and then come back
when it's finished and know that I have _everything_ I actually need to
have a working and documented product in one shot.
Right. The only reason for splitting the distribution is to cater to the
fictitious crowd with "bandwidth problems" or those that explicitly know
that they don't need the rest. There will still be a canonical full
tarball with everything, or at least I will not put my name to something
that abolishes it. In fact, I didn't like the idea of the split tarballs
in the first place, I'm merely changing the split to something more
useful.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [lockhart@alumni.caltech.edu: [HACKERS] Third call for platform testing]
matthew green [EMAIL PROTECTED] writes: i also believe the `Bad address' errors were caused when the test was run in an NFS mounted directory. You may have something, there. My test run on the VAX was over NFS. I set up NetBSD on a VAX specifically to test PostgreSQL 7.1, but I didn't have any disk available that it could use, so I went for NFS. -tih -- The basic difference is this: hackers build things, crackers break them. ---(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] Postgress on Windows
Hi-- This is my first time at using Postgress , and I would like to install it on a Win 2000 machine .HELP !!! Thanks Nadim ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: libtcl
I believe what we are talking about is diff, I am trying to install pltcl language on my db not pgmonitor. When I wand to build a pltcl.so, I got following msg, I want to know there's any wrong? Thanks anyway. Jie LIANG St. Bernard Software 10350 Science Center Drive Suite 100, San Diego, CA 92121 Office:(858)320-4873 [EMAIL PROTECTED] www.stbernard.com www.ipinc.com On Sat, 7 Apr 2001, Bruce Momjian wrote: No, I was wrong in even mentioning libpgtcl. You don't even need that. pgmonitor does not connect to the database at any time. I should run as a shell script if you have tcl/tk = 8.0 installed. What I need to do to install libtcl Do I still need to createlang -d dbname pltcl?? and when?? Jie LIANG St. Bernard Software 10350 Science Center Drive Suite 100, San Diego, CA 92121 Office:(858)320-4873 [EMAIL PROTECTED] www.stbernard.com www.ipinc.com On Sat, 7 Apr 2001, Bruce Momjian wrote: You don't need pltcl, just libtcl. I tried to intall pltcl, but failed when I tried to build a pltcl.so it seems hangging on there forever, what's wrong?? su-2.04# cd /work/src/pgsql702/src/pl/tcl/ su-2.04# ls CVS mkMakefile.tcldefs.sh.in INSTALL modules Makefilepltcl.c license.terms pltcl_guide.nr mkMakefile.tcldefs.sh test su-2.04# gmake Makefile:22: Makefile.tcldefs: No such file or directory /bin/sh ./mkMakefile.tcldefs.sh ^Cgmake: *** Deleting file `Makefile.tcldefs' gmake: *** [Makefile.tcldefs] Interrupt Jie LIANG St. Bernard Software 10350 Science Center Drive Suite 100, San Diego, CA 92121 Office:(858)320-4873 [EMAIL PROTECTED] www.stbernard.com www.ipinc.com -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Postgress On Windows
Hi-- This is my first time at using Postgress , and I would like to install it on a Win 2000 machine .HELP !!! Thanks Nadim ---(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] RPMS for RC3
Lamar Owen writes: Uploaded. Please take a look. ftp://ftp.postgresql.org/pub/dev/test-rpms There _are_ changes. I will detail the changes for the RC4 RPMset. Coupla issues: I'm confused about the logging. You install a logrotate configuration which talks about a file /var/log/postgresql, but the spec file creates a directory /var/log/pgsql/. Meanwhile, the start script you provide sends the log output to /dev/null. stop() in the init script should use pg_ctl -m fast. PGVERSION in the init script is still at beta6. Maybe you should track this from the source or the spec file. You're still shipping old jar files. You could build them from the source package. In 'make COPT="$CFLAGS" all', the COPT shouldn't be used. You should export CFLAGS before running configure. (What about CXXFLAGS?) Before long, 'cp /usr/lib/python1.5/config/Makefile.pre.in .' is going to get out of date. There's already Python 1.6 and 2.0. Since you're configuring --with-python, the work you do there isn't necessary anyway, since 'make all' takes care of it. 'make -C doc' is a no-op. Also, the docs are installed automatically, the stuff you do under '# man pages' needs some work. You probably want to run gzip on the files after installation. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] RPMS for RC3
Peter Eisentraut wrote:
Coupla issues:
I'm confused about the logging. You install a logrotate configuration
which talks about a file /var/log/postgresql, but the spec file creates a
directory /var/log/pgsql/
I'll correct that. The logrotate script (which I guess to prevent
confusion should just simply Go Away) was intended to roll a syslog()
log file, after the postinstall scriptlet added a line to
/etc/syslog.conf to place the logs in a good location -- however, as
good solid way of doing that has eluded me at this time -- mostly thanks
to the fact that these RPMs get installed as part of the OS install of
many distributions, meaning I have to carefully choose what utilities I
use during a %pre or %post scriptlet.
However, I may back down from that position and just document HOW to
setup logging in the README -- these RPMs shouldn't really try to be the
final shipping version for every distribution out there -- they should
just be a good foundation for any distribution that wants to ship
PostgreSQL. The least I can get away with doing, the better. And the
least I assume, the better. The current RPMset is far from this ideal,
as there are many RedHatisms that translate poorly to some
distributions.
. Meanwhile, the start script you provide sends
the log output to /dev/null.
Yes. As statedabout, logging was intended to be completely done via
syslog for ease of rotation as well as consistency withthe target
distribution.
stop() in the init script should use pg_ctl -m fast.
Why? The stop() may or may not be called as part of system shutdown --
and I have no real way of knowing which. The system shutdown variety
certainly could use fast -- but the manual variety? Minor issue,
though. Might just put the fast in there if there's no good reason not
to.
PGVERSION in the init script is still at beta6. Maybe you should track
this from the source or the spec file.
Argh. Typo. Yes, a better versioning system is needed. I'll certainly
correct the version before final. But since I'm getting ready to put
all the RPM's ancilliary files and some build-time scripts into CVS on
greatbridge.org, I'll do a version tracking from the spec file macros
across all scripts as part of that effort.
You're still shipping old jar files. You could build them from the source
package.
With which JDK? As Red Hat doesn't ship a _standard_ JDK, which one is
appropriate? Or, what is the _standard_ JDK?
In 'make COPT="$CFLAGS" all', the COPT shouldn't be used. You should
export CFLAGS before running configure. (What about CXXFLAGS?)
Ok.
Before long, 'cp /usr/lib/python1.5/config/Makefile.pre.in .' is going to
get out of date. There's already Python 1.6 and 2.0. Since you're
configuring --with-python, the work you do there isn't necessary anyway,
since 'make all' takes care of it.
Does make all in the python interface properly handle DESTDIR for
correct RPM_BUILD_ROOT handling? At that point, I'll certainly change
that -- but I had enough trouble with the Perl interface's handling or
mishandling of that -- IOW DESTDIR didn't in the Perl interface
--necessitating three builds of the interface to get it properly linked.
'make -C doc' is a no-op.
Ok -- now it is, 7.0 it wasn't. I'll pull it out and see what happens
or doesn't happen.
Also, the docs are installed automatically, the
stuff you do under '# man pages' needs some work.
The man pages are still in a separate tarball, or not?
You probably want
to run gzip on the files after installation.
Done automagically by the buildrootpolicy of the rpm build system, on
distributions that do buildrootpolicies, which are standard in late
3.0.x RPM as well as 4.x RPM. This is one of the reasons the %{_mandir}
macro is used for all man pages.
Thanks for taking the time to look (again).
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RPM upgrade caveats going from a beta version to RC
The Hermit Hacker wrote: We do, we follow the scheme as used by ... the BSD camp :) Be thankful we don't go all the way and use 7.2-RELEASE too :) If we had 7.1-CURRENT, 7.1-RELEASE, and 7.1-STABLE, the versioning comparision would be just fine -- better than now. As it stands, an upgrade from 7.1beta6 to 7.1RC4 and from 7.1RC4 to 7.1 is in the eyes of at least two packaging systems a downgrade. However, 7.1beta6 to 7.1rc4 to 7.1.0 would be an ok progression, as 7.1 7.1.0, I think (saying that without having tested it could be dangerous :-)). Although I must observe that if RPM used the system's locale in determining version collation, 7.1RC4 would be greater than 7.1beta6 -- which collation breaks our indexing and our LIKE optimizations, and breaks our regression tests. :-) But 7.1 would still be a downgrade based on that. Red Hat uses a different system for their betas -- which I'm not necessarily advocating, just presenting: The public RedHat beta, IIRC, for what may or may not become Red Hat 7.1 carried a version of 7.0.91. But then again the Linux kernel did that as well, going from 0.13 or so to 0.97 (and various pl numbers) before hitting 1.0. And just _why_ are you so adversarial to the Linux version numbering? After all, it's just another system. (Rhetorical question -- I already know the answer) :-) Personally, I think the Linux versioning is overkill, and prefer the BSD way of labeling versions. But that is just my personal opinion. But even at that, the Linux and BSD versioning is designed more for carrying concurrent STABLE and CURRENT versions -- we don't really have _that_ much version overlap to deal with, do we? Debian does as much -- but it is again a matter of version concurrency -- we're not likely to release a 7.1.0 then a 7.0.4 that fixes bugs in the STABLE branch, whereas at one point Linux 2.0.39, a 2.2.x, and 2.4.0 were being released concurrently. The same happens with FreeBSDand others -- but not us. -- 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] Re: [ANNOUNCE] PostgreSQL v7.1 Release Candidate 4
Where can I get a Postscript version docs for 7.1?
--
Tatsuo Ishii
Ladies and Gentlemen ...
Its been a long, arduous, up hill battle to get to this point, with all of
the changes since v7.0 was released, but we're finally there ...
The PostgreSQL Global Development Group is *pleased* to announce the
availability of PostgreSQL v7.1 Release Candidate 4, the long awaited
successor to v7.0.
Before anyone asks what a 'Release Candidate' is, and what happened to
1-3 ... a Release Candidate is what the developers have decided is going
to be the Release, based on no known bugs remaining, but want to get more
general testing.
If, by Friday, April 13th, there have been no bugs reported, all that will
happen is that rc4 will get renamed as the official release, no
repackaging or anything ...
What happened to 1-3? We packaged 1, one of the developers came across a
bug before an announcement went out, so we didn't announce ... similar to
the other 2.
Please NOTE that this is *not* the official release ... this is what we
believe, at this time, is going to be the official release, based on
extensive testing over the past several months, but if someone reports a
bug based on this, it will be addressed and a new package built ...
What does v7.1 provide that v7.0 didn't? From our HISTORY file:
Major changes in this release:
Write-ahead Log (WAL) - To maintain database consistency in case
of an operating system crash, previous releases of PostgreSQL have forced
all data modifications to disk before each transaction commit. With WAL,
only one log file must be flushed to disk, greatly improving performance.
If you have been using -F in previous releases to disable disk flushes,
you may want to consider discontinuing its use.
TOAST - Previous releases had a compiled-in row length limit,
typically 8 - 32 kB. This limit made storage of long text fields
difficult. With TOAST, long rows of any length can be stored with good
performance.
Outer Joins - We now support outer joins. The UNION/NOT IN
workaround for outer joins is no longer required. We use the SQL92 outer
join syntax.
Function Manager - The previous C function manager did not handle
NULLs properly, nor did it support 64-bit CPU's (Alpha). The new function
manager does. You can continue using your old custom functions, but you
may want to rewrite them in the future to use the new function manager
call interface.
Complex Queries - A large number of complex queries that were
unsupported in previous releases now work. Many combinations of views,
aggregates, UNION, LIMIT, cursors, subqueries, and inherited tables now
work properly. Inherited tables are now accessed by default. Subqueries
in FROM are now supported.
=
For a more complete list of New Features and Bugs Fixed, please read the
HISTORY segment available at:
ftp://ftp.postgresql.org/pub/README.v7_1
Source code is available at ftp://ftp.postgresql.org/pub/v7.1 ...
Please report any bugs that you encounter to [EMAIL PROTECTED]
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
[HACKERS] Yellow Dog Linux/PPC regression
Regression tests for Yellow Dog Linux (PPC RedHat derivative) failed all over the place with 7.0.3. Passed smoothly with 7.1RC3, though. I've got details if anybody's curious. -nat ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] --tuning compile and runtime option (?)
Hi guys, Just thinking about the future directions PostgreSQL is taking, and it seems (just a feeling) like most people prefer it to be as self tuning as possible. In trying to think about how it will/would do that I think PostgreSQL will need to know "how much" of the resources of the server its on, it's allowed to take. Can think of three scenario's, 1) Single-purpose PostgreSQL server 2) shared function server (i.e. Apache, Postgres, etc on the same box) 3) Embedded or otherwise resource limited server (Palmtop, etc). When we get around to PostgreSQL's self-tuning ability being actively developed (and I think Bruce has done some of the very start with his monitor program), perhaps having a compile time option to set the default for the server, and a runtime option in case it changes? i.e. --tuning=superserver --tuning=shared --tuning=embedded postmaster -t superserver postmaster -t shared postmaster -t embedded What do people think? Regards and best wishes, Justin Clift P.S. - I'm not on the Hackers mailing list from this account. Can anyone responding please include me directly in their replies? -- "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] --tuning compile and runtime option (?)
My idea was to have PostgreSQL output tips to help performance. The TODO item is: * Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM ANALYZE, and CLUSTER I also will be writing an article on performance tuning this month. What parameters would these options you suggest control? I usually prefer options that have more concrete effect. Just thinking about the future directions PostgreSQL is taking, and it seems (just a feeling) like most people prefer it to be as self tuning as possible. In trying to think about how it will/would do that I think PostgreSQL will need to know "how much" of the resources of the server its on, it's allowed to take. Can think of three scenario's, 1) Single-purpose PostgreSQL server 2) shared function server (i.e. Apache, Postgres, etc on the same box) 3) Embedded or otherwise resource limited server (Palmtop, etc). When we get around to PostgreSQL's self-tuning ability being actively developed (and I think Bruce has done some of the very start with his monitor program), perhaps having a compile time option to set the default for the server, and a runtime option in case it changes? i.e. --tuning=superserver --tuning=shared --tuning=embedded postmaster -t superserver postmaster -t shared postmaster -t embedded What do people think? Regards and best wishes, Justin Clift P.S. - I'm not on the Hackers mailing list from this account. Can anyone responding please include me directly in their replies? -- "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]) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] --tuning compile and runtime option (?)
[ Charset ISO-8859-1 unsupported, converting... ] I like this. Ensure that tips can be dumped into a log file -- preferably separate from the main one -- so it can be run on a live system for a short period of time, recorded then analyzed later. Yes, they would go into the standard postmaster log. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
