PostgreSQL v7.2b2 Released

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

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

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

* 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

* 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

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

* Bruce Momjian (pgman@candle.pha.pa.us) [011108 13:10]:

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

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

If I wasn't clear, yes, that's what I think should happen.

Added to TODO.

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

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

On Thu, 8 Nov 2001, bpalmer wrote:

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

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

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

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

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

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