Thread

PostgreSQL v7.2b2 Released

Marc Fournier <scrappy@hub.org> — 2001-11-07T23:43:06Z

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

Re: [HACKERS] PostgreSQL v7.2b2 Released

Martin Marques <martin@bugs.unl.edu.ar> — 2001-11-08T12:02:11Z

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
-----------------------------------------------------------------

OT?: PGReplication project dead?

Bradley McLean <brad@bradm.net> — 2001-11-08T16:44:08Z

Asked here in case anyone else is in the same situation.

I was lurking on pgreplication-general@greatbridge.org.
Unsurprisingly, it appears to be gone.

The TODO list at http://developer.postgresql.org/todo.php does not
appear to have any links to the state of the project, beyond the
page of old hacker's list messages from dec to july.

Darren, or someone, would you please post a link or two?  And might
I humbly suggest that for a project listed at the very top under
urgent, it would be nice to make it easy to find?

Thanks,

-Brad

Re: OT?: PGReplication project dead?

bpalmer <bpalmer@crimelabs.net> — 2001-11-08T17:23:41Z

> I was lurking on pgreplication-general@greatbridge.org.
> Unsurprisingly, it appears to be gone.

There actually is work being done.  However,  since the list of off line,
there is a lot of communication via email between Darren and I and Betina
(and a few others).  Once the list comes back,  Darren will be posting all
that was discussed there.  We have the 6.4 version working and are moving
the code to 7.2ish to work from that point on.  There are a lot of new
features in 7.2,  however,  that need to be considered.

So...

It is being worked on,  but w/o a mailing list up,  it's hard to get the
info out.  Please mail Darren or myself if you care to know more.

> Darren, or someone, would you please post a link or two?  And might
> I humbly suggest that for a project listed at the very top under
> urgent, it would be nice to make it easy to find?

The info is now available on gborg:

http://gborg.postgresql.org/project/pgreplication/projdisplay.php

- Brandon


----------------------------------------------------------------------------
 c: 646-456-5455                                            h: 201-798-4983
 b. palmer,  bpalmer@crimelabs.net           pgp:crimelabs.net/bpalmer.pgp5

Re: OT?: PGReplication project dead?

Bradley McLean <brad@bradm.net> — 2001-11-08T17:40:02Z

* bpalmer (bpalmer@crimelabs.net) [011108 12:28]:
> 
> It is being worked on,  but w/o a mailing list up,  it's hard to get the
> info out.  Please mail Darren or myself if you care to know more.

Thanks, Brandon;  Good to hear.  

Is replacing the list a work in process?  Is assistance required?

> http://gborg.postgresql.org/project/pgreplication/projdisplay.php

Would I be out of line in suggesting this get grafted into the TODO
list?  And possibly the projects page?  Bruce?

-Brad

Re: OT?: PGReplication project dead?

Bruce Momjian <pgman@candle.pha.pa.us> — 2001-11-08T18:14:41Z

> * bpalmer (bpalmer@crimelabs.net) [011108 12:28]:
> > 
> > It is being worked on,  but w/o a mailing list up,  it's hard to get the
> > info out.  Please mail Darren or myself if you care to know more.
> 
> Thanks, Brandon;  Good to hear.  
> 
> Is replacing the list a work in process?  Is assistance required?
> 
> > http://gborg.postgresql.org/project/pgreplication/projdisplay.php
> 
> Would I be out of line in suggesting this get grafted into the TODO
> list?  And possibly the projects page?  Bruce?

Sure.  I wonder if I should just put that URL on the TODO list.

-- 
  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 19026

Re: OT?: PGReplication project dead?

bpalmer <bpalmer@crimelabs.net> — 2001-11-08T18:17:03Z

> Is replacing the list a work in process?  Is assistance required?

That is a gborg issue.  We could setup a list on one of our servers,  but
it would be better just to get the old list back up.

> Would I be out of line in suggesting this get grafted into the TODO
> list?  And possibly the projects page?  Bruce?

I think that it would be smarter to hyperlink to the URL than to graft the
info onto the TODO,  that seems like overkill and replication is being
developed in parallel with the main tree as was the full text search stuff
and will be merged in at the proper time.

- Brandon


----------------------------------------------------------------------------
 c: 646-456-5455                                            h: 201-798-4983
 b. palmer,  bpalmer@crimelabs.net           pgp:crimelabs.net/bpalmer.pgp5

Re: OT?: PGReplication project dead?

Marc Fournier <scrappy@hub.org> — 2001-11-08T18:33:15Z

Not sure what the status is of it being back online ... Chris?


On Thu, 8 Nov 2001, bpalmer wrote:

> > I was lurking on pgreplication-general@greatbridge.org.
> > Unsurprisingly, it appears to be gone.
>
> There actually is work being done.  However,  since the list of off line,
> there is a lot of communication via email between Darren and I and Betina
> (and a few others).  Once the list comes back,  Darren will be posting all
> that was discussed there.  We have the 6.4 version working and are moving
> the code to 7.2ish to work from that point on.  There are a lot of new
> features in 7.2,  however,  that need to be considered.
>
> So...
>
> It is being worked on,  but w/o a mailing list up,  it's hard to get the
> info out.  Please mail Darren or myself if you care to know more.
>
> > Darren, or someone, would you please post a link or two?  And might
> > I humbly suggest that for a project listed at the very top under
> > urgent, it would be nice to make it easy to find?
>
> The info is now available on gborg:
>
> http://gborg.postgresql.org/project/pgreplication/projdisplay.php
>
> - Brandon
>
>
> ----------------------------------------------------------------------------
>  c: 646-456-5455                                            h: 201-798-4983
>  b. palmer,  bpalmer@crimelabs.net           pgp:crimelabs.net/bpalmer.pgp5
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

Re: [HACKERS] PostgreSQL v7.2b2 Released

Jeff Davis <list-pgsql-general@dynworks.com> — 2001-11-08T19:15:38Z

> 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... :-)

Re: [HACKERS] PostgreSQL v7.2b2 Released

Tom Lane <tgl@sss.pgh.pa.us> — 2001-11-09T01:24:42Z

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

Re: Postgre for Windows

Brent R. Matzelle <bmatzelle@yahoo.com> — 2001-11-09T14:30:34Z

--- 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

Postgre for Windows

Frans Thamura <fth4mura@yahoo.com> — 2001-11-09T20:47:45Z

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

psql -f backup.out || file too big

Jorge Sarmiento <jsarmiento@ccom.org> — 2001-11-10T01:52:58Z

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

Re: OT?: PGReplication project dead?

Chris Ryan <ryan@postgresql.org> — 2001-11-11T03:36:14Z

As far as I know the PGReplication project is still alive. Darren E-mails about 
once a week checking on the mail list status. At this point I have the mailing 
lists semi-functional. Archives are working and the administration of lists 
works for the most part.  I haven't had enough time of late to finish getting 
the server setup to actually send/receive mail. When I get there I plan on 
sending out a mass mailing to all the lists.

Chris Ryan


Quoting "Marc G. Fournier" <scrappy@hub.org>:

> 
> Not sure what the status is of it being back online ... Chris?
> 
> 
> On Thu, 8 Nov 2001, bpalmer wrote:
> 
> > > I was lurking on pgreplication-general@greatbridge.org.
> > > Unsurprisingly, it appears to be gone.
> >
> > There actually is work being done.  However,  since the list of off
> line,
> > there is a lot of communication via email between Darren and I and
> Betina
> > (and a few others).  Once the list comes back,  Darren will be posting
> all
> > that was discussed there.  We have the 6.4 version working and are
> moving
> > the code to 7.2ish to work from that point on.  There are a lot of
> new
> > features in 7.2,  however,  that need to be considered.
> >
> > So...
> >
> > It is being worked on,  but w/o a mailing list up,  it's hard to get
> the
> > info out.  Please mail Darren or myself if you care to know more.
> >
> > > Darren, or someone, would you please post a link or two?  And
> might
> > > I humbly suggest that for a project listed at the very top under
> > > urgent, it would be nice to make it easy to find?
> >
> > The info is now available on gborg:
> >
> > http://gborg.postgresql.org/project/pgreplication/projdisplay.php
> >
> > - Brandon
> >
> >
> >
> ----------------------------------------------------------------------------
> >  c: 646-456-5455                                            h:
> 201-798-4983
> >  b. palmer,  bpalmer@crimelabs.net          
> pgp:crimelabs.net/bpalmer.pgp5
> >
> >
> > ---------------------------(end of
> broadcast)---------------------------
> > TIP 4: Don't 'kill -9' the postmaster
> >
> 
>

Re: psql -f backup.out || file too big

Janning Vygen <vygen@planwerk6.de> — 2001-11-12T09:08:22Z

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

Re: psql -f backup.out || file too big - SOLVED

Jorge Sarmiento <jsarmiento@ccom.org> — 2001-11-12T16:09:01Z

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)

Re: psql -f backup.out || file too big - SOLVED

Helge Bahmann <bahmann@math.tu-freiberg.de> — 2001-11-12T17:26:31Z

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)            |