beta3

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Are we doing beta3 soon? I thought we were going to do it yesterday,
though it seems like we have a few packaging problems to iron out first.

The packaging problems need to be solved before we can build a release
candidate --- but I don't see why they should hold up beta3. beta2 has
the same problems, so beta3 wouldn't be a regression.

I don't have any pending work that ought to go in beta3, but I think
Thomas is sitting on some datetime patches ... probably should wait
for him.

regards, tom lane

Tom Lane writes:

The packaging problems need to be solved before we can build a release
candidate --- but I don't see why they should hold up beta3. beta2 has
the same problems, so beta3 wouldn't be a regression.

Considering the history of how-do-we-get-the-docs-in-the-tarball problem,
I'd like to see at least one beta where this works before shipping a
release candidate. Otherwise I'll have no confidence at all that we're
not going to ship the final release with last year's docs and no man
pages.

--
Peter Eisentraut peter_e@gmx.net

Okay, how do we want to address/fix/test this?

On Sun, 18 Nov 2001, Peter Eisentraut wrote:

Marc G. Fournier writes:

Okay, how do we want to address/fix/test this?

Assuming that we don't want to make sweeping changes to the overall
procedure, I suggest this:

1. The postgres.tar.gz and man.tar.gz documentation tarballs required for
a release used to be at ftp://ftp.postgresql.org/pub/dev/doc/. The new
file system location of this directory needs to be determined.

2. Some postgres.tar.gz and man.tar.gz files need to be put there.

3. The currently commented out portion in the mk-release script needs
to be altered to pick up these files.

(I also suggest 'set -e' in this script so it doesn't ignore errors.)

4. The HTML-doc-build cron job needs to be reinstated on postgresql.org
and put its output file at the new location.

5. When I'm done with the new manpages I'll upload them to the
appropriate location.

I think the answer to #1 is /var/spool/ftp or something. For #2, use the
postgres.tar.gz files that Bruce currently builds, and use the old
man.tar.gz file from 7.1.

I suggest when #3 is done we can ship a beta3.

For #4, I don't know who wants to do it. If it's me then it might take a
few days. #5 is well under way. When #4 and #5 are done we can ship rc1
or beta4, depending on the other issues.

--
Peter Eisentraut peter_e@gmx.net

On Mon, 19 Nov 2001, Peter Eisentraut wrote:

Marc G. Fournier writes:

Okay, how do we want to address/fix/test this?

Assuming that we don't want to make sweeping changes to the overall
procedure, I suggest this:

1. The postgres.tar.gz and man.tar.gz documentation tarballs required for
a release used to be at ftp://ftp.postgresql.org/pub/dev/doc/. The new
file system location of this directory needs to be determined.

Should simply be ~ftp/pub/dev/doc

2. Some postgres.tar.gz and man.tar.gz files need to be put there.

3. The currently commented out portion in the mk-release script needs
to be altered to pick up these files.

(I also suggest 'set -e' in this script so it doesn't ignore errors.)

Okay, just added 'set -e', commented out, to the script ... actually, just
uncommented it, for, even without the docs, it probably shouldn't be
ignored, eh? :)

4. The HTML-doc-build cron job needs to be reinstated on
postgresql.org and put its output file at the new location.

5. When I'm done with the new manpages I'll upload them to the
appropriate location.

I think the answer to #1 is /var/spool/ftp or something. For #2, use the
postgres.tar.gz files that Bruce currently builds, and use the old
man.tar.gz file from 7.1.

I suggest when #3 is done we can ship a beta3.

Okay, will bundle up Beta3 in the morning then ...

For #4, I don't know who wants to do it. If it's me then it might
take a few days. #5 is well under way. When #4 and #5 are done we
can ship rc1 or beta4, depending on the other issues.

Would #4 be these, from thomas old cron jobs:

# Run at 3:05 local time (EST5EDT?) every day
5 3 * * * $HOME/CURRENT/docbuild |& tee $HOME/CURRENT/docbuild.log
# Twice a day during beta 2000-03-28
25 11 * * * $HOME/CURRENT/docbuild |& tee $HOME/CURRENT/docbuild.log

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Peter Eisentraut
Sent: Monday, 19 November 2001 10:40 PM
To: Marc G. Fournier
Cc: Tom Lane; Bruce Momjian; PostgreSQL-development; Thomas Lockhart
Subject: Re: [HACKERS] beta3

Marc G. Fournier writes:

Okay, how do we want to address/fix/test this?

Assuming that we don't want to make sweeping changes to the overall
procedure, I suggest this:

1. The postgres.tar.gz and man.tar.gz documentation tarballs required for
a release used to be at ftp://ftp.postgresql.org/pub/dev/doc/. The new
file system location of this directory needs to be determined.

2. Some postgres.tar.gz and man.tar.gz files need to be put there.

Just a thought: Doesn't everyone have bzip2 these days? Many large
projects come bz2-only even these days. Is there a good reason to stick
with the extra-large tar.gz format?

Chris

On Tue, 20 Nov 2001, Christopher Kings-Lynne wrote:

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Peter Eisentraut
Sent: Monday, 19 November 2001 10:40 PM
To: Marc G. Fournier
Cc: Tom Lane; Bruce Momjian; PostgreSQL-development; Thomas Lockhart
Subject: Re: [HACKERS] beta3

Marc G. Fournier writes:

Okay, how do we want to address/fix/test this?

Assuming that we don't want to make sweeping changes to the overall
procedure, I suggest this:

1. The postgres.tar.gz and man.tar.gz documentation tarballs required for
a release used to be at ftp://ftp.postgresql.org/pub/dev/doc/. The new
file system location of this directory needs to be determined.

2. Some postgres.tar.gz and man.tar.gz files need to be put there.

Just a thought: Doesn't everyone have bzip2 these days? Many large
projects come bz2-only even these days. Is there a good reason to stick
with the extra-large tar.gz format?

Cause not everyone has bzip2 ... Solaris comes with gzip, doesn't come
with bzip ... not sure how many other OS, but even FreeBSD requiresyou to
compile bzip from ports, it isn't part of hte operating system ...

Cause not everyone has bzip2 ... Solaris comes with gzip, doesn't come
with bzip ... not sure how many other OS, but even FreeBSD requiresyou to
compile bzip from ports, it isn't part of hte operating system ...

FreeBSD 4.4 has it as part of the OS...

For example, the entire KDE project is bz2, and people use it on Solaris.

But anyway, fair enough - I guess it's an extra step that would inhibit the
use of Postgres.

Chris

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cause not everyone has bzip2 ...

Why not have both, so the user can choose? Many other
things on the net do just that. That way, I can choose
bz2 for a quick download, or use gz if I am using an
inferior OS :)

While we're on the subject, how about digitally signing the
releases as well? An MD5 checksum is fine, but certainly
won't protect against trojans and other maliciousness that
a pgp signature could prevent.

Greg Sabino Mullane
greg@turnstep.com
PGP Key: 0x14964AC8 200111191132

-----BEGIN PGP SIGNATURE-----
Comment: http://www.turnstep.com/pgp.html

iQA/AwUBO/nc+7ybkGcUlkrIEQLBPgCeM6CXgV0W7WjJBwGhiVj6u8hjPJ8An3Os
fP8flAAcciNI6FfOPyXKsD1B
=00M7
-----END PGP SIGNATURE-----

On Lun 19 Nov 2001 22:49, you wrote:

On Tue, 20 Nov 2001, Christopher Kings-Lynne wrote:

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Peter
Eisentraut Sent: Monday, 19 November 2001 10:40 PM
To: Marc G. Fournier
Cc: Tom Lane; Bruce Momjian; PostgreSQL-development; Thomas Lockhart
Subject: Re: [HACKERS] beta3

Marc G. Fournier writes:

Okay, how do we want to address/fix/test this?

Assuming that we don't want to make sweeping changes to the overall
procedure, I suggest this:

1. The postgres.tar.gz and man.tar.gz documentation tarballs required
for a release used to be at ftp://ftp.postgresql.org/pub/dev/doc/. The
new file system location of this directory needs to be determined.

2. Some postgres.tar.gz and man.tar.gz files need to be put there.

Just a thought: Doesn't everyone have bzip2 these days? Many large
projects come bz2-only even these days. Is there a good reason to stick
with the extra-large tar.gz format?

Cause not everyone has bzip2 ... Solaris comes with gzip, doesn't come
with bzip ... not sure how many other OS, but even FreeBSD requiresyou to
compile bzip from ports, it isn't part of hte operating system ...

Go to www.sunfreeware.com and get bzip2 for Solaris.
I even recompiled the new tar with support for bzip2! :-)

Saludos... :-)

P.D.: bzip2 is slow, but you can get a real small package with it, even
though PostgreSQL isn't that big, if we compare it with KDE or Mozilla.

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

=?iso-8859-1?q?Mart=EDn=20Marqu=E9s?= <martin@bugs.unl.edu.ar> writes:

P.D.: bzip2 is slow, but you can get a real small package with it, even
though PostgreSQL isn't that big, if we compare it with KDE or Mozilla.

As an experiment, I zipped my current PG source tree with both. (This
isn't an exact test of the distribution size, because I didn't bother
to get rid of the CVS control files, but it's pretty close.)

Original tar file: 37089280 bytes
gzip -9: 8183182 bytes
bzip2: 6762638 bytes

or slightly less than a 20% savings for bzip over gzip. That's useful,
but not exactly compelling. A comparison of unzip runtime also seems
relevant:

$ time gunzip pgsql.tar.gz

real 0m5.48s
user 0m4.46s
sys 0m0.62s

$ time bunzip2 pgsql.tar.bz2

real 0m27.77s
user 0m26.50s
sys 0m0.92s

If I'd downloaded this thing over a decent DSL or cable modem line,
bzip2 would actually be a net loss in total download + uncompress time.

<editorial>
The reason bzip is still an also-ran is that it's not enough better
than gzip to have persuaded people to switch over. My bet is that
bzip will always be an also-ran, and that gzip will remain the de
facto standard until something comes along that's really significantly
better, like a factor of 2 better. I've watched this sort of game
play out before, and I know you don't take over the world with a 20%
improvement over the existing standard. At least not without other
compelling reasons, like speed (oops) or patent freedom (no win there
either).
</editorial>

regards, tom lane

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

If I'd downloaded this thing over a decent DSL or cable modem
line, bzip2 would actually be a net loss in total
download + uncompress time.

I think the download time is a lot more important to people than
the uncompression time. A savings of nearly 1.5 Megs is
significant, no matter what type of line you are on. If we can
shave off 1.5M for a 56K user, why not?

My runtime tests were also different:

bzip -9: 8.959 real
bzip -1: 7.473 real
gzip -9: 1.491 real

That's not much of a difference, and (IMO) is more than offset
by the smaller download size. Bandwidth should be a more
important factor: after all, the next few steps (tar,
configure, make) are going to make the unzipping seem fast
in comparison. :)

I'm not advocating *replacing* gzip with bzip2, but I do think
we should make it an option. It should not be that much
trouble.

Digital signatures, on the other hand, are a lot more trouble
but are much more important than the gzip/bzip2 issue....

Greg Sabino Mullane
greg@turnstep.com
PGP Key: 0x14964AC8 200111201606

-----BEGIN PGP SIGNATURE-----
Comment: http://www.turnstep.com/pgp.html

iQA/AwUBO/rG+LybkGcUlkrIEQJO8wCdGlZgyQUTYwLUMTrSwcmmnUx0nlYAn37H
I6W1G8h+7jQIIiBTuHQeKQB7
=PtZi
-----END PGP SIGNATURE-----

"Greg Sabino Mullane" <greg@turnstep.com> writes:

If I'd downloaded this thing over a decent DSL or cable modem
line, bzip2 would actually be a net loss in total
download + uncompress time.

I think the download time is a lot more important to people than
the uncompression time. A savings of nearly 1.5 Megs is
significant, no matter what type of line you are on.

And for CD space (I'd love bzipped binaries), ftp space, etc (not only
for mirrors, but for distributions shipping postgresql and mirrors
thereeof.

--
Trond Eivind Glomsr�d
Red Hat, Inc.

On Mar 20 Nov 2001 12:16, Tom Lane wrote:

As an experiment, I zipped my current PG source tree with both. (This
isn't an exact test of the distribution size, because I didn't bother
to get rid of the CVS control files, but it's pretty close.)

Original tar file: 37089280 bytes
gzip -9: 8183182 bytes
bzip2: 6762638 bytes

or slightly less than a 20% savings for bzip over gzip. That's useful,
but not exactly compelling. A comparison of unzip runtime also seems
relevant:

$ time gunzip pgsql.tar.gz

real 0m5.48s
user 0m4.46s
sys 0m0.62s

$ time bunzip2 pgsql.tar.bz2

real 0m27.77s
user 0m26.50s
sys 0m0.92s

If I'd downloaded this thing over a decent DSL or cable modem line,
bzip2 would actually be a net loss in total download + uncompress time.

That would be if I have a decent DSL or cable modem. We have a dedicated line
of 756 kb, but we also have 3000 users. Maybe postgreSQL isn't that big, but
Mozilla or KDE are, and waiting for la large download isn't what I recommend
for an internet experience. :-)

<editorial>
The reason bzip is still an also-ran is that it's not enough better
than gzip to have persuaded people to switch over. My bet is that
bzip will always be an also-ran, and that gzip will remain the de
facto standard until something comes along that's really significantly
better, like a factor of 2 better. I've watched this sort of game
play out before, and I know you don't take over the world with a 20%
improvement over the existing standard. At least not without other
compelling reasons, like speed (oops) or patent freedom (no win there
either).
</editorial>

I think it comes to what CPU I'm using. If I'm on an old Pentium, I may not
be happy seeing unbzip2 grabbing all my CPU, but if I'm on a last generation
PIV of, lets say 1000Mhz, I may not feel it.

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

On 20 Nov 2001, Trond Eivind [iso-8859-1] Glomsr���d wrote:

"Greg Sabino Mullane" <greg@turnstep.com> writes:

If I'd downloaded this thing over a decent DSL or cable modem
line, bzip2 would actually be a net loss in total
download + uncompress time.

I think the download time is a lot more important to people than
the uncompression time. A savings of nearly 1.5 Megs is
significant, no matter what type of line you are on.

And for CD space (I'd love bzipped binaries), ftp space, etc (not only
for mirrors, but for distributions shipping postgresql and mirrors
thereeof.

Huh? You are advocating adding to the ftp space required? *raised
eyebrow*

Okay, tried today what you suggested, about set -e and all that ... take a
look at ~pgsql/bin/mk-beta, to see if maybe I missed something ... but,
trying to do the packaging, I'm getting an error about 'build.xml'?

/usr/bin/tar cf postgresql-opt-7.2b3.tar postgresql-7.2b3/src/backend/utils/mb postgresql-7.2b3/contrib/retep postgresql-7.2b3/build.xml postgresql-7.2b3/src/tools postgresql-7.2b3/src/corba postgresql-7.2b3/src/data postgresql-7.2b3/src/tutorial postgresql-7.2b3/src/bin/pgaccess postgresql-7.2b3/src/bin/pgtclsh postgresql-7.2b3/src/bin/pg_encoding postgresql-7.2b3/src/interfaces/odbc postgresql-7.2b3/src/interfaces/libpq++ postgresql-7.2b3/src/interfaces/libpgtcl postgresql-7.2b3/src/interfaces/perl5 postgresql-7.2b3/src/interfaces/python postgresql-7.2b3/src/interfaces/jdbc postgresql-7.2b3/src/pl/plperl postgresql-7.2b3/src/pl/tcl
/usr/bin/tar: can't add file postgresql-7.2b3/build.xml : No such file or directory
gmake: *** [postgresql-opt-7.2b3.tar] Error 1
gmake: *** Deleting file `postgresql-opt-7.2b3.tar'
%

Looking in the wrong directory?

%find . -name build.xml -print
./contrib/retep/build.xml
./src/interfaces/jdbc/build.xml
%

On Mon, 19 Nov 2001, Peter Eisentraut wrote:

Okay, tried today what you suggested, about set -e and all that ... take a
look at ~pgsql/bin/mk-beta, to see if maybe I missed something ... but,
trying to do the packaging, I'm getting an error about 'build.xml'?

/usr/bin/tar cf postgresql-opt-7.2b3.tar postgresql-7.2b3/src/backend/utils/mb postgresql-7.2b3/contrib/retep postgresql-7.2b3/build.xml postgresql-7.2b3/src/tools postgresql-7.2b3/src/corba postgresql-7.2b3/src/data postgresql-7.2b3/src/tutorial postgresql-7.2b3/src/bin/pgaccess postgresql-7.2b3/src/bin/pgtclsh postgresql-7.2b3/src/bin/pg_encoding postgresql-7.2b3/src/interfaces/odbc postgresql-7.2b3/src/interfaces/libpq++ postgresql-7.2b3/src/interfaces/libpgtcl postgresql-7.2b3/src/interfaces/perl5 postgresql-7.2b3/src/interfaces/python postgresql-7.2b3/src/interfaces/jdbc postgresql-7.2b3/src/pl/plperl postgresql-7.2b3/src/pl/tcl
/usr/bin/tar: can't add file postgresql-7.2b3/build.xml : No such file or directory
gmake: *** [postgresql-opt-7.2b3.tar] Error 1
gmake: *** Deleting file `postgresql-opt-7.2b3.tar'
%

Looking in the wrong directory?

%find . -name build.xml -print
./contrib/retep/build.xml
./src/interfaces/jdbc/build.xml
%

OK, patch applied. There was a space where there should have been a
slash.

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

Okay, tried today what you suggested, about set -e and all that ... take a
look at ~pgsql/bin/mk-beta, to see if maybe I missed something ... but,
trying to do the packaging, I'm getting an error about 'build.xml'?

/usr/bin/tar cf postgresql-opt-7.2b3.tar postgresql-7.2b3/src/backend/utils/mb postgresql-7.2b3/contrib/retep postgresql-7.2b3/build.xml postgresql-7.2b3/src/tools postgresql-7.2b3/src/corba postgresql-7.2b3/src/data postgresql-7.2b3/src/tutorial postgresql-7.2b3/src/bin/pgaccess postgresql-7.2b3/src/bin/pgtclsh postgresql-7.2b3/src/bin/pg_encoding postgresql-7.2b3/src/interfaces/odbc postgresql-7.2b3/src/interfaces/libpq++ postgresql-7.2b3/src/interfaces/libpgtcl postgresql-7.2b3/src/interfaces/perl5 postgresql-7.2b3/src/interfaces/python postgresql-7.2b3/src/interfaces/jdbc postgresql-7.2b3/src/pl/plperl postgresql-7.2b3/src/pl/tcl
/usr/bin/tar: can't add file postgresql-7.2b3/build.xml : No such file or directory
gmake: *** [postgresql-opt-7.2b3.tar] Error 1
gmake: *** Deleting file `postgresql-opt-7.2b3.tar'
%

Looking in the wrong directory?

%find . -name build.xml -print
./contrib/retep/build.xml
./src/interfaces/jdbc/build.xml
%

OK, patch applied. There was a space where there should have been a
slash.

OK, I found another problem:

gzip -f --best postgresql-base-7.2b3.tar
/usr/bin/tar cf postgresql-docs-7.2b3.tar
postgresql-7.2b3/doc/postgres.tar.gz postgresql-7.2b3/doc/src

^^^^^^^^^^^^^^^^^^^
postgresql-7.2b3/doc/TODO.detail postgresql-7.2b3/doc/internals.ps
/usr/bin/tar: can't add file postgresql-7.2b3/doc/postgres.tar.gz : No

^^^^^^^^^^^^^^^^^^^

such file or directory

The problem is this line in pgsql/GNUmakefile.in:

docs_files := doc/postgres.tar.gz doc/src doc/TODO.detail doc/internals.ps

Why is doc/postgres.tar.gz used. It normally is in doc/src, and why
only that doc tarball.

And again, there is that intenrals.ps file that doesn't really belong
there, I think.

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

On Tue, Nov 20, 2001 at 10:16:57AM -0500, Tom Lane wrote:

Original tar file: 37089280 bytes
gzip -9: 8183182 bytes
bzip2: 6762638 bytes

maybe 1.420.544 it's not a big difference for you, but here in italy
there's still a lot of people using 33.6/55Kb telephone line modem.
so, this difference means, downloading at 3kb/s, seven minutes...
also:

a) cpu utilization has no cost... band cost a lot;
b) if i have to download 5 files, and i can avoid 1 MB of download for each
one...

thanks for your time,
andrea gelmini

OK, I found another problem:

gzip -f --best postgresql-base-7.2b3.tar
/usr/bin/tar cf postgresql-docs-7.2b3.tar
postgresql-7.2b3/doc/postgres.tar.gz postgresql-7.2b3/doc/src

^^^^^^^^^^^^^^^^^^^
postgresql-7.2b3/doc/TODO.detail postgresql-7.2b3/doc/internals.ps
/usr/bin/tar: can't add file postgresql-7.2b3/doc/postgres.tar.gz : No

^^^^^^^^^^^^^^^^^^^

such file or directory

The problem is this line in pgsql/GNUmakefile.in:

docs_files := doc/postgres.tar.gz doc/src doc/TODO.detail doc/internals.ps

Why is doc/postgres.tar.gz used. It normally is in doc/src, and why
only that doc tarball.

OK, I updated this to point to doc/src. Marc, I have a
doc/postgres.tar.gz here that you can use to make the tarball. It is
now at ftp://candle.pha.pa.us/pub/postgresql.

And again, there is that intenrals.ps file that doesn't really belong
there, I think.

Tom agrees so I will move it to the web site. Shame we don't have the
source, which was originally TeX.

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

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

On 20 Nov 2001, Trond Eivind [iso-8859-1] Glomsr�d wrote:

"Greg Sabino Mullane" <greg@turnstep.com> writes:

If I'd downloaded this thing over a decent DSL or cable modem
line, bzip2 would actually be a net loss in total
download + uncompress time.

I think the download time is a lot more important to people than
the uncompression time. A savings of nearly 1.5 Megs is
significant, no matter what type of line you are on.

And for CD space (I'd love bzipped binaries), ftp space, etc (not only
for mirrors, but for distributions shipping postgresql and mirrors
thereeof.

Huh? You are advocating adding to the ftp space required? *raised
eyebrow*

Replace gz with bz2, and you'll save :) - also, bzipped files will
allow others who only ship one instance (like us - we only need one
tarball for the SRPM), and these will save space.

--
Trond Eivind Glomsr�d
Red Hat, Inc.

On Wed, Nov 21, 2001 at 10:30:54AM -0500, Bruce Momjian wrote:

And again, there is that intenrals.ps file that doesn't really belong
there, I think.

Tom agrees so I will move it to the web site. Shame we don't have the
source, which was originally TeX.

Digging in the archives, I find that the author of this doc offered
the source:

Date: Wed, 13 Jan 1999 06:04:15 +0000
From: Clark Evans <clark.evans@manhattanproject.com>
Subject: Re: [HACKERS] Re: EXCEPT/INTERSECT for v6.4

Thomas,

The documentation Stefan wrote for his Master's thesis
is great stuff. Perhaps some of could be incorporated?

Stefan Simkovics wrote:

I also included the text of my Master's Thesis. (a postscript
version). I hope that you find something of it useful and would be
happy if parts of it find their way into the PostgreSQL documentation
project (If so, tell me, then I send the sources of the document!)

If we can track down his current email address, perhaps he still has it?
I'm copying this to his @ag.or.at address, since the mailer there still
recognizes it. Let's see if Stefan's around. ;-)

Ross (musing if he could find the source docs to his Ph.D. thesis ... and
if so, if they'd be readable)

--
Ross Reedstrom, Ph.D. reedstrm@rice.edu
Executive Director phone: 713-348-6166
Gulf Coast Consortium for Bioinformatics fax: 713-348-6182
Rice University MS-39
Houston, TX 77005

Stefan Simkovics wrote:

I also included the text of my Master's Thesis. (a postscript
version). I hope that you find something of it useful and would be
happy if parts of it find their way into the PostgreSQL documentation
project (If so, tell me, then I send the sources of the document!)

If we can track down his current email address, perhaps he still has it?
I'm copying this to his @ag.or.at address, since the mailer there still
recognizes it. Let's see if Stefan's around. ;-)

Ross (musing if he could find the source docs to his Ph.D. thesis ... and
if so, if they'd be readable)

The thesis was in LaTeX. I think Thomas may have copy, but I am not sure.

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

Hi!

As you can see, the address is still valid :-)
Could you please let me know exactly , who is looking for what?

Then I can send you a LaTeX/PDF/PS Version of my thesis.

best regards

Stefan Simkovics

Stefan Simkovics wrote:

I also included the text of my Master's Thesis. (a postscript
version). I hope that you find something of it useful and would be
happy if parts of it find their way into the PostgreSQL documentation
project (If so, tell me, then I send the sources of the document!)

If we can track down his current email address, perhaps he still has it?
I'm copying this to his @ag.or.at address, since the mailer there still
recognizes it. Let's see if Stefan's around. ;-)

Ross (musing if he could find the source docs to his Ph.D. thesis ... and
if so, if they'd be readable)

The thesis was in LaTeX. I think Thomas may have copy, but I am not sure.

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

--
=====================================================================
DI Stefan Simkovics
KPNQwest Austria GmbH
A-1150 Wien, Diefenbachgasse 35
Tel.: +43 (1) 899 33 - 162, Fax: +43 (1) 899 33 - 10 162
Mob.: +43 (0) 664 818 91 41, e-Mail: stefan.simkovics@kpnqwest.com
http://www.kpnqwest.at, http://www.kpnqwest.com

Hi!

As you can see, the address is still valid :-)
Could you please let me know exactly , who is looking for what?

Then I can send you a LaTeX/PDF/PS Version of my thesis.

I think we wanted the Latex source.

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

Hi!

Could you please let me know the reason you're looking for it?
(I'm just curious :-))

best regards

Stefan

Hi!

As you can see, the address is still valid :-)
Could you please let me know exactly , who is looking for what?

Then I can send you a LaTeX/PDF/PS Version of my thesis.

I think we wanted the Latex source.

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

--
=====================================================================
DI Stefan Simkovics
KPNQwest Austria GmbH
A-1150 Wien, Diefenbachgasse 35
Tel.: +43 (1) 899 33 - 162, Fax: +43 (1) 899 33 - 10 162
Mob.: +43 (0) 664 818 91 41, e-Mail: stefan.simkovics@kpnqwest.com
http://www.kpnqwest.at, http://www.kpnqwest.com

Hi!

Could you please let me know the reason you're looking for it?
(I'm just curious :-))

That's an excellent question. We moved the Postscript file out of the
main CVS into the web page CVS because it wasn't really source code.

Of course, if we had the LaTeX, it would be documentation source code.
However, we have no intention of modifying it, so am not sure what value
the LaTeX would be to us.

Guys, why did we want the source, exactly? I think just putting the
Postscript on the web site is enough.

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

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Guys, why did we want the source, exactly?

I just said that source for the document would be appropriate to keep
in CVS whereas the PS output was not. I'm not sure that we really want
the document, though, since we're not using it as actual documentation
(ie, it's not being updated to reflect changes in the system).

regards, tom lane

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Guys, why did we want the source, exactly?

I just said that source for the document would be appropriate to keep
in CVS whereas the PS output was not. I'm not sure that we really want
the document, though, since we're not using it as actual documentation
(ie, it's not being updated to reflect changes in the system).

Yea, that was my reading too. I will convert the PS to PDF and add it
to the web site. I think that's the way to go.

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

On Wed, Nov 21, 2001 at 01:36:15PM -0500, Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Guys, why did we want the source, exactly?

I just said that source for the document would be appropriate to keep
in CVS whereas the PS output was not. I'm not sure that we really want
the document, though, since we're not using it as actual documentation
(ie, it's not being updated to reflect changes in the system).

Perhaps because it _can't_ be updated, without the source? A number of
people have commented on how it's a good write up of internals of query
processing. Unfortunately, it's circa v. 6.3, and starting to show it's
age. If the source were available, pulling out sections and updating them
is at least a possibility. Otherwise, it's just a historical document:
interesting, but fading.

Stefan, could you see your way to putting it under an Open Content
license of some sort, so it could be used in this way?

Ross

OK, here is where I think we are on beta3 packaging.

Last night, I fixed the error Marc was seeing in the build. I have also
put my HTML version of the docs at:

ftp://candle.pha.pa.us/pub/postgresql/postgres-docs.tar.gz.

If that is copied to doc/src and mk-beta is run, it should work fine.

Also, can the beta directory be removed from the snapshot tar file?

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

On Wed, 21 Nov 2001, Bruce Momjian wrote:

OK, here is where I think we are on beta3 packaging.

Last night, I fixed the error Marc was seeing in the build. I have also
put my HTML version of the docs at:

ftp://candle.pha.pa.us/pub/postgresql/postgres-docs.tar.gz.

If that is copied to doc/src and mk-beta is run, it should work fine.

Okay, we have a ~ftp/pub/doc/current, but no src ... what is the
difference between current and src?

Also, its reporting that internals.ps is missing ...

On Wed, 21 Nov 2001, Bruce Momjian wrote:

OK, here is where I think we are on beta3 packaging.

Last night, I fixed the error Marc was seeing in the build. I have also
put my HTML version of the docs at:

ftp://candle.pha.pa.us/pub/postgresql/postgres-docs.tar.gz.

If that is copied to doc/src and mk-beta is run, it should work fine.

Okay, we have a ~ftp/pub/doc/current, but no src ... what is the
difference between current and src?

I meant copy into pgsql/doc/src or wherever directory tree you are using
to make the beta. Does that make sense?

Also, its reporting that internals.ps is missing ...

OK, sorry, fixed. Please rerun configure to get the new code.

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

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

Also, its reporting that internals.ps is missing ...

Looks like Bruce forgot to remove the reference in the toplevel
GNUmakefile.in.

regards, tom lane

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

Also, its reporting that internals.ps is missing ...

Looks like Bruce forgot to remove the reference in the toplevel
GNUmakefile.in.

Yea, I removed it only from GNUmakefile the first time. Got it now.

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

Okay, how do we want to address/fix/test this?

On Sun, 18 Nov 2001, Peter Eisentraut wrote:

Tom Lane writes:

The packaging problems need to be solved before we can build a release
candidate --- but I don't see why they should hold up beta3. beta2 has
the same problems, so beta3 wouldn't be a regression.

Considering the history of how-do-we-get-the-docs-in-the-tarball problem,
I'd like to see at least one beta where this works before shipping a
release candidate. Otherwise I'll have no confidence at all that we're
not going to ship the final release with last year's docs and no man
pages.

The best we can do at this point is to package my HTML files for beta3
and see if we can test this for RC1. At least the tar.gz file itself
will be added by the script, just not built on the same machine.

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

Bruce Momjian writes:

The problem is this line in pgsql/GNUmakefile.in:

docs_files := doc/postgres.tar.gz doc/src doc/TODO.detail doc/internals.ps

Why is doc/postgres.tar.gz used. It normally is in doc/src, and why
only that doc tarball.

OK, I updated this to point to doc/src.

Nooooooooooooooooooooooooooooo!

--
Peter Eisentraut peter_e@gmx.net

Bruce Momjian writes:

OK, I found another problem:

gzip -f --best postgresql-base-7.2b3.tar
/usr/bin/tar cf postgresql-docs-7.2b3.tar
postgresql-7.2b3/doc/postgres.tar.gz postgresql-7.2b3/doc/src

^^^^^^^^^^^^^^^^^^^
postgresql-7.2b3/doc/TODO.detail postgresql-7.2b3/doc/internals.ps
/usr/bin/tar: can't add file postgresql-7.2b3/doc/postgres.tar.gz : No

^^^^^^^^^^^^^^^^^^^

such file or directory

Well, I sent you the list with items 1 through 5 and if you process them
in a different order then all bets are off.

The problem is this line in pgsql/GNUmakefile.in:

docs_files := doc/postgres.tar.gz doc/src doc/TODO.detail doc/internals.ps

Why is doc/postgres.tar.gz used. It normally is in doc/src, and why
only that doc tarball.

No, this is correct.

And again, there is that intenrals.ps file that doesn't really belong
there, I think.

--
Peter Eisentraut peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:

OK, I updated this to point to doc/src.

Nooooooooooooooooooooooooooooo!

If it's wrong, please fix it.

*Somebody's* got to take responsibility for making the doc build process
work again on postgresql.org. I don't have the foggiest idea what's wrong
or where to look. You and Marc (and Thomas, except he's gone for awhile)
are the only candidate fixers in sight.

regards, tom lane

Bruce Momjian writes:

The problem is this line in pgsql/GNUmakefile.in:

docs_files := doc/postgres.tar.gz doc/src doc/TODO.detail doc/internals.ps

Why is doc/postgres.tar.gz used. It normally is in doc/src, and why
only that doc tarball.

OK, I updated this to point to doc/src.

Nooooooooooooooooooooooooooooo!

OK, I put it back. I don't know how this is supposed to work. Marc, if
you put the postgresql.tar.gz in /doc instead of doc/src as I said
before, it should work.

Again, I am just trying to jump start this thing so we can get on to beta3.

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

On Wed, 21 Nov 2001, Bruce Momjian wrote:

Okay, how do we want to address/fix/test this?

On Sun, 18 Nov 2001, Peter Eisentraut wrote:

Tom Lane writes:

The packaging problems need to be solved before we can build a release
candidate --- but I don't see why they should hold up beta3. beta2 has
the same problems, so beta3 wouldn't be a regression.

Considering the history of how-do-we-get-the-docs-in-the-tarball problem,
I'd like to see at least one beta where this works before shipping a
release candidate. Otherwise I'll have no confidence at all that we're
not going to ship the final release with last year's docs and no man
pages.

The best we can do at this point is to package my HTML files for beta3
and see if we can test this for RC1. At least the tar.gz file itself
will be added by the script, just not built on the same machine.

Is there a reason why it can't be built on the same machine, by the script
that builds the package itself? Is there something remaining missing on
the server that prevents this from happening?

On Wed, 21 Nov 2001, Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

OK, I updated this to point to doc/src.

Nooooooooooooooooooooooooooooo!

If it's wrong, please fix it.

*Somebody's* got to take responsibility for making the doc build process
work again on postgresql.org. I don't have the foggiest idea what's wrong
or where to look. You and Marc (and Thomas, except he's gone for awhile)
are the only candidate fixers in sight.

and, right now, I don't know what is "broken" that needs to be fixed ...
Peter, my fingers are at y our disposal, what haven't I installed yet? :(

The best we can do at this point is to package my HTML files for beta3
and see if we can test this for RC1. At least the tar.gz file itself
will be added by the script, just not built on the same machine.

Is there a reason why it can't be built on the same machine, by the script
that builds the package itself? Is there something remaining missing on
the server that prevents this from happening?

Uh, I don't know. It needs the SGML tools stuff. Is that working?

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

Peter and I are discussing this off list and will let y'all know once we
get it working again ... once we do, beta3 will come out ...

On Wed, 21 Nov 2001, Bruce Momjian wrote:

Is he awake? It is Thu Nov 22 03:50:21 GMT 2001.

---------------------------------------------------------------------------

Peter and I are discussing this off list and will let y'all know once we
get it working again ... once we do, beta3 will come out ...

On Wed, 21 Nov 2001, Bruce Momjian wrote:

The best we can do at this point is to package my HTML files for beta3
and see if we can test this for RC1. At least the tar.gz file itself
will be added by the script, just not built on the same machine.

Is there a reason why it can't be built on the same machine, by the script
that builds the package itself? Is there something remaining missing on
the server that prevents this from happening?

Uh, I don't know. It needs the SGML tools stuff. Is that working?

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

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

Tom Lane wrote:

<editorial>
The reason bzip is still an also-ran is that it's not enough better
than gzip to have persuaded people to switch over. My bet is that
bzip will always be an also-ran, and that gzip will remain the de
facto standard until something comes along that's really significantly
better, like a factor of 2 better. I've watched this sort of game
play out before, and I know you don't take over the world with a 20%
improvement over the existing standard. At least not without other
compelling reasons, like speed (oops) or patent freedom (no win there
either).
</editorial>

While agree in principle with your view on bzip2, I think there is a strong
reason why you should use it, 20%

That 20% is quite valuable. Just by switching to bzip2, the hosting companies
can deliver 20% more downloads with the same equipment and bandwidth cost. The
people with slow connections can get it 20% faster.

Will bzip2 become the standard? Probably not in general use, but for
downloadable tarballs it is rapidly becoming the standard. Those who pay for
bandwidth (server or client) welcome any improvement possible.

I would switch the argument around, time how long it takes to do:

ncftpget postgresql-xxxx.tar.gz
tar xpzvf postgresql-xxxx.tar.gz
cd postgresql-xxxx
./configure --option
make
make install

vs

ncftpget postgresql-xxxx.tar.bz2
bunzip2 -c postgresql-xxxx.tar.bz2 | tar xpzv
cd postgresql-xxxx
./configure --option
make
make install

The total time involved is almost identical, plus or minus a few seconds, but
on slow connections: users get postgresql faster and have to tie up a phone
line for a shorter amount of time.

The hosting company can serve 20% less bandwidth.
The archive takes up 20% less space on the mirrors.
The archine takes up 20% less space on server backups.

I don't think there is a compelling reason to keep a gzipped version.

On Vie 23 Nov 2001 13:10, mlw wrote:

While agree in principle with your view on bzip2, I think there is a strong
reason why you should use it, 20%

That 20% is quite valuable. Just by switching to bzip2, the hosting
companies can deliver 20% more downloads with the same equipment and
bandwidth cost. The people with slow connections can get it 20% faster.

Will bzip2 become the standard? Probably not in general use, but for
downloadable tarballs it is rapidly becoming the standard. Those who pay
for bandwidth (server or client) welcome any improvement possible.

I would switch the argument around, time how long it takes to do:

ncftpget postgresql-xxxx.tar.gz
tar xpzvf postgresql-xxxx.tar.gz
cd postgresql-xxxx
./configure --option
make
make install

vs

ncftpget postgresql-xxxx.tar.bz2
bunzip2 -c postgresql-xxxx.tar.bz2 | tar xpzv

New versions of tar would do this:

tar xpjvf postgresql-xxxx.tar.gz

It comes with bzip2 support.

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

...

Perhaps because it _can't_ be updated, without the source? A number of
people have commented on how it's a good write up of internals of query
processing. Unfortunately, it's circa v. 6.3, and starting to show it's
age. If the source were available, pulling out sections and updating them
is at least a possibility. Otherwise, it's just a historical document:
interesting, but fading.
Stefan, could you see your way to putting it under an Open Content
license of some sort, so it could be used in this way?

Stefan already authorized us to use it anyway that we see fit, but we
*do* need to preserve the attribution for himself and his academic
advisor and institution.

Some/much of the source is commented out in cvs source code (latex
markup and all) in the repository afaicr (don't have my laptop fired up
at the moment) because I was worried about losing it otherwise. Since
then, I've of course lost the original sources afaict.

- Thomas