PostgreSQL v7.1 Release Candidate 4
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 pgsql-bugs@postgresql.org
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
Where can I get a Postscript version docs for 7.1?
--
Tatsuo Ishii
Show quoted text
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 pgsql-bugs@postgresql.org
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
Where can I get a Postscript version docs for 7.1?
I'll start building hardcopy in the next day or two, and hope that it
will be done quickly (more quickly that in previous releases). Will keep
y'all informed on the progress...
- Thomas
Hi all,
On Sun, 8 Apr 2001, The Hermit Hacker wrote:
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 ...
Was hoping that I'd have some time to get around to it before now, but I
haven't so am posting to the list. For quite some time I have found the
behaviour of CLUSTER to be deceiving. The documentation has some to say
about its short comings.
The table is actually copied to a temporary table in index order, then
renamed back to the original name. For this reason, all grant
permissions and other indexes are lost when clustering is performed.
It also drops the other relation meta data. I think this should at least
be noted in the documentation for 7.1 full release or the heap copy should
look at copying over triggers, checks etc.
Sorry to chime in so close to release, I only just looked to see if this
had been addressed.
Thanks
Gavin
Hi all,
On Sun, 8 Apr 2001, The Hermit Hacker wrote:
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 ...Was hoping that I'd have some time to get around to it before now, but I
haven't so am posting to the list. For quite some time I have found the
behaviour of CLUSTER to be deceiving. The documentation has some to say
about its short comings.The table is actually copied to a temporary table in index order, then
renamed back to the original name. For this reason, all grant
permissions and other indexes are lost when clustering is performed.It also drops the other relation meta data. I think this should at least
be noted in the documentation for 7.1 full release or the heap copy should
look at copying over triggers, checks etc.
Can you give me specific text? I though 7.1 was a little better about
preserving the metadata.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026Bruce,
Problem is the use of heap_drop_with_catalog().
* heap_drop_with_catalog - removes all record of named
relation from catalogs
*
* 1) open relation, check for existence, etc.
* 2) remove inheritance information
* 3) remove indexes
* 4) remove pg_class tuple
* 5) remove pg_attribute tuples and related descriptions
* 6) remove pg_description tuples
* 7) remove pg_type tuples
* 8) RemoveConstraints ()
* 9) unlink relation
Only these things are destroyed. relchecks, for example, stays consistent
and works correctly.
Gavin
