Thread: PostgreSQL v7.2b2 Released

Good evening ...

    Back on October 25th, 2001, the PostgreSQL Global Development
Group quietly released Beta1 of PostgreSQL v7.2, in order to get the first
round of packaging and testing of our upcoming release in motion.

    Today, almost two weeks later and with few major bugs reported, we
are please to announce our second Beta for broader testing.

    v7.2 of PostgreSQL includes over 6 months of development since we
released v7.1 back in April, 2001, and, as with all our releases, contains
more improvements, enhancements and bug fixes then one would put into an
email.

    Major highlights for this release include:

        VACUUM -  VACUUM no longer locks tables, allowing normal user
access during the VACUUM.  A new VACUUM FULL command does old-style
vacuum by locking the table and shrinking the on-disk copy of the table.

        Transactions - There is no longer a problem with installations
that exceed four billion transactions.

        OID's - OID's are now optional.  Users can now create tables
without OID's for cases where OID usage is excessive.

        Optimizer - The system now computes histogram column statistics
during ANALYZE, allowing much better optimizer choices.

        Security -  A new MD5 encryption option allows much more secure
storage and transfer of passwords.  A new unix-domain socket
authentication option is available on Linux and *BSD systems.

        Statistics -  Administrators can use the new table access
statistics module to get fine-grained information about table and index
usage.

        Internationalization - Error messages can now be displayed in
several languages.

    With a complete list of changes listed in the HISTORY file.

    As well, as with all of our major releases, v7.2 will require a
complete dump and restore when upgrading from previous versions.

    v7.2b2 is available at ftp://ftp.postgresql.org, as well as
through all of our official mirror sites.

    Bug reports, as always, should be directed to
pgsql-bugs@postgresql.org, and the severity of all bugs reported will
determine whether we move to the release cycle, or do another Beta, so we
encourage as many administrators as possible to test this current release.


Marc G. Fournier
Coordinator, PGDG

On Mié 07 Nov 2001 20:43, you wrote:
> Good evening ...
>
>     Back on October 25th, 2001, the PostgreSQL Global Development
> Group quietly released Beta1 of PostgreSQL v7.2, in order to get the first
> round of packaging and testing of our upcoming release in motion.
>
>     Today, almost two weeks later and with few major bugs reported, we
> are please to announce our second Beta for broader testing.
>
>     v7.2 of PostgreSQL includes over 6 months of development since we
> released v7.1 back in April, 2001, and, as with all our releases, contains
> more improvements, enhancements and bug fixes then one would put into an
> email.
>
>     Major highlights for this release include:
>
>         VACUUM -  VACUUM no longer locks tables, allowing normal user
> access during the VACUUM.  A new VACUUM FULL command does old-style
> vacuum by locking the table and shrinking the on-disk copy of the table.

What does VACUUM do if it doesn´t shrink the size of the database?

Saludos... :-)

--
Porqué usar una base de datos relacional cualquiera,
si podés usar PostgreSQL?
-----------------------------------------------------------------
Martín Marqués                  |        mmarques@unl.edu.ar
Programador, Administrador, DBA |       Centro de Telematica
                       Universidad Nacional
                            del Litoral
-----------------------------------------------------------------

> What does VACUUM do if it doesn´t shrink the size of the database?
>

I was wondering the same thing, so I looked at the development docs and it
appears that regular VACUUM frees the dead tuples so that the space on a page
may be reused. This approach doesn't actually reduce the number of pages
allocated though, it reduces the chances that more pages will be allocated
(because the pages have free space to make tuples in). VACUUM FULL packs all
the tuples together and actually reduces the number of allocated pages. You
should be able to run a DB 24x7 by issuing only VACUUM without the disk usage
growing out of control.

Jeff Davis

> Saludos... :-)

Jeff Davis <list-pgsql-general@dynworks.com> writes:
> I was wondering the same thing, so I looked at the development docs
> and it appears that regular VACUUM frees the dead tuples so that the
> space on a page may be reused. This approach doesn't actually reduce
> the number of pages allocated though, it reduces the chances that more
> pages will be allocated (because the pages have free space to make
> tuples in).

Maybe the docs still need some work on this point.  Plain VACUUM will
still try to reduce the number of pages in a table, but it does so only
by removing wholly-empty end pages.  (And it won't move tuples across
pages to make end pages empty, which turns out to have been the single
slowest, most complex action old-style VACUUM performs.)  Also, it
can't remove any pages unless it can secure a temporary exclusive lock
on the table while it does so --- but unlike old-style VACUUM, it
doesn't insist on being able to do so.  If there are concurrent
readers/writers then it just forgets about truncating the table and
moves on.

Bottom line is that it's a pretty laid-back approach to reclaiming
disk space.  I believe that it will work pretty well for maintaining
a steady-state average disk usage of heavily updated tables, but in
cases such as having just deleted 80% of the tuples in a table (that
you're not planning to refill just as fast) a VACUUM FULL might still
be appropriate.

I expect we'll be experimenting with the behavior for awhile to come.

            regards, tom lane

Where I can get the Postgre Win binary version..

So, I just install and run it

frans


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

--- Frans Thamura <fth4mura@yahoo.com> wrote:
> Where I can get the Postgre Win binary version..
>
> So, I just install and run it

Download Cygwin (http://cygwin.com/).

Brent

__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com

Hello everybody!

I am trying to restore a 2.5 Gb. backup file made using pg_dumpall, and I get
the "file too big" error message from postgres

what can I do to solve this? is this a bug? I have 18 Gb. free disk space, a
two PIII processor machine with 1 Gb. ram, running Red Hat 7.1 with
Postgresql 7.1.3 (installed from official rpms)

thank in advance for your help!

greetings!

Jorge Sarmiento

I solved my problem, it was quite easy, and the error was cause by a
limitation of the psql proggie.

the solution was:

psql < backup.out

instead of

psql -f backup.out

according to the man pages, using "psql -f" or "psql <" would give us the
same result, but the -f parameter will give us "better messages"...

what that psql -f limit documented somewhere?

thanx all for your help!

Jorge S.

On Friday 09 November 2001 08:52 pm, Jorge Sarmiento wrote:
> Hello everybody!
>
> I am trying to restore a 2.5 Gb. backup file made using pg_dumpall, and I
> get the "file too big" error message from postgres
>
> what can I do to solve this? is this a bug? I have 18 Gb. free disk space,
> a two PIII processor machine with 1 Gb. ram, running Red Hat 7.1 with
> Postgresql 7.1.3 (installed from official rpms)
>
> thank in advance for your help!
>
> greetings!
>
> Jorge Sarmiento
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

On Mon, 12 Nov 2001, Jorge Sarmiento wrote:

[backup.out > 2GB]
> the solution was:
>
> psql < backup.out
>
> instead of
>
> psql -f backup.out
[...]
> what that psql -f limit documented somewhere?

This is not a limitation of psql, but of lacking "large file support"
selected at compile time.

If you recompile psql and add the option "-D_FILE_OFFSET_BITS=64" then
psql -f should work as well.

Regards
--
Helge Bahmann <bahmann@math.tu-freiberg.de>             /| \__
Network admin, systems programmer                      /_|____\
                                                     _/\ |   __)
$ ./configure                                        \\ \|__/__|
checking whether build environment is sane... yes     \\/___/ |
checking for AIX... no (we already did this)            |

Am Samstag, 10. November 2001 02:52 schrieb Jorge Sarmiento:

> I am trying to restore a 2.5 Gb. backup file made using pg_dumpall,
> and I get the "file too big" error message from postgres

Its not a bug in postgres i guess. your filesystem reports an error.
You can use a zip utility like gzip. Just pipe your dump to your
favorite zip programm and zip it on the fly before you write it to
your dump_file.

if it´s still to big use 'split' to split your dump over various
files.

It´s documented in Chapter 8:  8.1.3 Large Databases in "Practical
PostgreSQL" It is not printed yet i think, but its available online.

I can send you a copy of this page per PM if you like.

Janning


--
Planwerk 6 /websolutions
Herzogstraße 86
40215 Düsseldorf

fon 0211-6015919
fax 0211-6015917
http://www.planwerk6.de