Thread: 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
> 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?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>
> 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, Pennsylvania19026
Bruce, 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 inheritanceinformation* 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
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Can you give me specific text? I though 7.1 was a little better about
> preserving the metadata.
Not in the least --- 7.1's CLUSTER is just as bad as ever.
regards, tom lane