postgres/alpha problems
well, it looks like we're moving postgres to a linux machine, so I
won't be doing any more alpha debugging for a while (BTW, adjusting
some types on the attribute struct to make it 64-bit aligned had no
effect) unless someone has some suggestions for me to try (aside from
the snapshot thing, I figure anyone with an alpha can do that. let me
know if I should). I haven't given up, however my free time is
limited and obviously I can't do it on my employer's penny anymore
(beleive it or not, I did have permission), and I'd also like to work
on pl/perl & odbc stuff.
also, cast (var to type) is the same as type(var)? weird! why
doesn't it just call the output/input functions (I can't cast name to
text or vice-versa for comparisons)..
also, cast (var to type) is the same as type(var)? weird! why
doesn't it just call the output/input functions (I can't cast name to
text or vice-versa for comparisons)..
If there is an explicit conversion routine available, it might be/should
be faster and more correct than converting to and from strings. The last
resort fallback could be the string strategy. I'd like to work on the
type conversion problem for v6.4...
- Tom
On Mon, 9 Mar 1998, Brett McCormick wrote:
well, it looks like we're moving postgres to a linux machine, so I
won't be doing any more alpha debugging for a while (BTW, adjusting
some types on the attribute struct to make it 64-bit aligned had no
effect) unless someone has some suggestions for me to try (aside from
the snapshot thing, I figure anyone with an alpha can do that. let me
know if I should). I haven't given up, however my free time is
limited and obviously I can't do it on my employer's penny anymore
(beleive it or not, I did have permission), and I'd also like to work
on pl/perl & odbc stuff.
Ok, I could do the cvs stuff. No promises about time, though. Marc? How
can we do it?
-------------------------------------------------------------------
Pedro José Lobo Perea Tel: +34 1 336 78 19
Centro de Cálculo Fax: +34 1 331 92 29
EUIT Telecomunicación - UPM e-mail: pjlobo@euitt.upm.es
On Tue, 10 Mar 1998, Pedro J. Lobo wrote:
On Mon, 9 Mar 1998, Brett McCormick wrote:
well, it looks like we're moving postgres to a linux machine, so I
won't be doing any more alpha debugging for a while (BTW, adjusting
some types on the attribute struct to make it 64-bit aligned had no
effect) unless someone has some suggestions for me to try (aside from
the snapshot thing, I figure anyone with an alpha can do that. let me
know if I should). I haven't given up, however my free time is
limited and obviously I can't do it on my employer's penny anymore
(beleive it or not, I did have permission), and I'd also like to work
on pl/perl & odbc stuff.Ok, I could do the cvs stuff. No promises about time, though. Marc? How
can we do it?
*pop head up* Do what? Only way of grabbing the current source
tree is via CVSup...I could make a tarball of the CVS repository available
as of the time of the v6.3 release, if that helps...?
The Hermit Hacker wrote:
On Tue, 10 Mar 1998, Pedro J. Lobo wrote:
On Mon, 9 Mar 1998, Brett McCormick wrote:
well, it looks like we're moving postgres to a linux machine, so I
won't be doing any more alpha debugging for a while (BTW, adjusting
some types on the attribute struct to make it 64-bit aligned had no
effect) unless someone has some suggestions for me to try (aside from
the snapshot thing, I figure anyone with an alpha can do that. let me
know if I should). I haven't given up, however my free time is
limited and obviously I can't do it on my employer's penny anymore
(beleive it or not, I did have permission), and I'd also like to work
on pl/perl & odbc stuff.Ok, I could do the cvs stuff. No promises about time, though. Marc? How
can we do it?*pop head up* Do what? Only way of grabbing the current source
tree is via CVSup...I could make a tarball of the CVS repository available
as of the time of the v6.3 release, if that helps...?
CVSup supports the "snapshot" idea directly. Use the "*default date"
parameter:
*default date=98.01.20.00.00.00
to retrieve the source tree as of midnight, January 20. I have used this
successfully just recently in trying to track down a problem. The nice thing
is that you can change this date and CVSup will roll back any more recent
changes without requiring you to download the entire tree, and afaik does all
the right things to make this work correctly.
My complete "oldtree" CVSup configuration file is enclosed below. Prepending
a "#" to the defaultdate parameter line will give you the usual behavior of
picking up the latest version of the tree.
- Tom
# This file represents the standard CVSup distribution file
# for the PostgreSQL ORDBMS project
# Modified by lockhart@alumni.caltech.edu 1997-08-28
# - Point to my local snapshot source tree
#
# Defaults that apply to all the collections
*default host=postgresql.org
*default compress
*default release=cvs
*default delete use-rel-suffix
*default tag=.
*default date=98.01.20.00.00.00
# base directory points to where CVSup will store its 'bookmarks' file(s)
*default base=/opt/postgres/oldtree # /usr/local/pgsql
# prefix directory points to where CVSup will store the actual
distribution(s)
*default prefix=/opt/postgres/oldtree # /usr/local/pgsql
# complete distribution, including all below
pgsql
# individual distributions vs 'the whole thing'
# pgsql-doc
# pgsql-perl5
# pgsql-src
On Tue, 10 Mar 1998, The Hermit Hacker wrote:
On Tue, 10 Mar 1998, Pedro J. Lobo wrote:
On Mon, 9 Mar 1998, Brett McCormick wrote:
won't be doing any more alpha debugging for a while (BTW, adjusting
some types on the attribute struct to make it 64-bit aligned had no
effect) unless someone has some suggestions for me to try (aside from
the snapshot thing, I figure anyone with an alpha can do that. let me
know if I should). I haven't given up, however my free time is
limited and obviously I can't do it on my employer's penny anymore
(beleive it or not, I did have permission), and I'd also like to work
on pl/perl & odbc stuff.Ok, I could do the cvs stuff. No promises about time, though. Marc? How
can we do it?*pop head up* Do what? Only way of grabbing the current source
tree is via CVSup...I could make a tarball of the CVS repository available
as of the time of the v6.3 release, if that helps...?
Ok, I thought I heard something about getting an account. If I can use
CVSup to get the CVS tree, that's fine. I'll let you know when/if I find
something interesting.
-------------------------------------------------------------------
Pedro José Lobo Perea Tel: +34 1 336 78 19
Centro de Cálculo Fax: +34 1 331 92 29
EUIT Telecomunicación - UPM e-mail: pjlobo@euitt.upm.es
On Tue, 10 Mar 1998, Thomas G. Lockhart wrote:
The Hermit Hacker wrote:
*pop head up* Do what? Only way of grabbing the current source
tree is via CVSup...I could make a tarball of the CVS repository available
as of the time of the v6.3 release, if that helps...?CVSup supports the "snapshot" idea directly. Use the "*default date"
parameter:*default date=98.01.20.00.00.00
[...]
Thanks for the info. I'll start investigating as soon as I can.
-------------------------------------------------------------------
Pedro José Lobo Perea Tel: +34 1 336 78 19
Centro de Cálculo Fax: +34 1 331 92 29
EUIT Telecomunicación - UPM e-mail: pjlobo@euitt.upm.es
On Tue, 10 Mar 1998, Pedro J. Lobo wrote:
On Mon, 9 Mar 1998, Brett McCormick wrote:
well, it looks like we're moving postgres to a linux machine, so I
won't be doing any more alpha debugging for a while (BTW, adjusting
some types on the attribute struct to make it 64-bit aligned had no
effect) unless someone has some suggestions for me to try (aside from
the snapshot thing, I figure anyone with an alpha can do that. let me
know if I should). I haven't given up, however my free time is
limited and obviously I can't do it on my employer's penny anymore
(beleive it or not, I did have permission), and I'd also like to work
on pl/perl & odbc stuff.Ok, I could do the cvs stuff. No promises about time, though. Marc? How
can we do it?*pop head up* Do what? Only way of grabbing the current source
tree is via CVSup...I could make a tarball of the CVS repository available
as of the time of the v6.3 release, if that helps...?
He needs a login to postgresql, and do cvs extracts based on date with
the -D option. He will test Jan 15, and go a month forward or backward,
until he finds the date that initdb fails.
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)CVSup supports the "snapshot" idea directly. Use the "*default date"
parameter:*default date=98.01.20.00.00.00
to retrieve the source tree as of midnight, January 20. I have used this
successfully just recently in trying to track down a problem. The nice thing
is that you can change this date and CVSup will roll back any more recent
changes without requiring you to download the entire tree, and afaik does all
the right things to make this work correctly.
Cool. Much better than using cvs directly. Let's get those Alpha's
fixed!
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)On Tue, 10 Mar 1998, Bruce Momjian wrote:
On Tue, 10 Mar 1998, Pedro J. Lobo wrote:
On Mon, 9 Mar 1998, Brett McCormick wrote:
well, it looks like we're moving postgres to a linux machine, so I
won't be doing any more alpha debugging for a while (BTW, adjusting
some types on the attribute struct to make it 64-bit aligned had no
effect) unless someone has some suggestions for me to try (aside from
the snapshot thing, I figure anyone with an alpha can do that. let me
know if I should). I haven't given up, however my free time is
limited and obviously I can't do it on my employer's penny anymore
(beleive it or not, I did have permission), and I'd also like to work
on pl/perl & odbc stuff.Ok, I could do the cvs stuff. No promises about time, though. Marc? How
can we do it?*pop head up* Do what? Only way of grabbing the current source
tree is via CVSup...I could make a tarball of the CVS repository available
as of the time of the v6.3 release, if that helps...?He needs a login to postgresql, and do cvs extracts based on date with
the -D option. He will test Jan 15, and go a month forward or backward,
until he finds the date that initdb fails.
It seems that I don't need such a thing. I am using cvsup right now, and
it seems to work well... except that it's been running for more than an
hour and I only have the 'COPYRIGHT' file :-( The overseas connection is
terribly slow. At night (between 0:00 and 7:00 MET, which is 18:00 - 1:00
EST, I think) it goes better, but that way I could only get (and try) one
snapshot each day. Slow, but... I am downloading now the Jan 1st tree.
We'll see what happens.
-------------------------------------------------------------------
Pedro José Lobo Perea Tel: +34 1 336 78 19
Centro de Cálculo Fax: +34 1 331 92 29
EUIT Telecomunicación - UPM e-mail: pjlobo@euitt.upm.es
ocie@paracel.com wrote:
Thomas G. Lockhart wrote:
[snip]
a "#" to the defaultdate parameter line will give you the usual behavior of
picking up the latest version of the tree.- Tom
# This file represents the standard CVSup distribution file
# for the PostgreSQL ORDBMS project
# Modified by lockhart@alumni.caltech.edu 1997-08-28
# - Point to my local snapshot source tree
#
# Defaults that apply to all the collections
*default host=postgresql.org
*default compress
*default release=cvs
*default delete use-rel-suffix
*default tag=.
*default date=98.01.20.00.00.00# base directory points to where CVSup will store its 'bookmarks' file(s)
*default base=/opt/postgres/oldtree # /usr/local/pgsql# prefix directory points to where CVSup will store the actual
distribution(s)
*default prefix=/opt/postgres/oldtree # /usr/local/pgsql# complete distribution, including all below
pgsql# individual distributions vs 'the whole thing'
# pgsql-doc
# pgsql-perl5
# pgsql-srcI am trying to get this working under Linux and behind a firewall. Do
you know of any cvsup documentation that might tell me how to set this
up? Or do you know how to set this up offhand?
afaik, the only thing you need to do is to install the CVSup client (I had
posted a static binary for linux; a dynamic binary would require the Modula-3
libraries and I wasn't sure how to link a partial dynamic binary with those
included).
Then, modify your configuration file (as was done in my example above) to point
to the right places on your system. Only the base directory needs to exist for
this to work (e.g. "/opt/postgres/oldtree") and CVSup will create the rest. To
execute CVSup, type
cvsup -L 2 postgres.cvsup
where "postgres.cvsup" is the name of your configuration file. The "-L 2" is a
verbosity setting. For my system, I include a path name in front of the
configuration file name, and have the whole thing aliased to a command "pgget",
so just typing that does the update from postgresql.org.
Building CVSup from scratch is not trivial, since Modula-3 must be installed
(~200MB to install, ~50MB installed) and then CVSup must be built, working
around some BSD-specific makefiles. Don't know if anyone has built a glibc2
version for us, or whether it is even necessary.
Good luck.
- Tom
Import Notes
Reference msg id not found: 9803101955.AA28415@dolomite.paracel.com | Resolved by subject fallback
"pjlobo" == Pedro J Lobo <pjlobo@euitt.upm.es> writes:
Stuff deleted.
It seems that I don't need such a thing. I am using cvsup right
now, and it seems to work well... except that it's been running
for more than an hour and I only have the 'COPYRIGHT' file :-(
The overseas connection is terribly slow. At night (between 0:00
and 7:00 MET, which is 18:00 - 1:00 EST, I think) it goes
better, but that way I could only get (and try) one snapshot
each day. Slow, but... I am downloading now the Jan 1st tree.
We'll see what happens.
Why get the snapshots instead of the entire RCS files using CVSUP?
use
*default release=cvs.
This allows you to create any possible snapshot, by checking out of
CVS. I have found this a much better way to track bugs. This does
require additional disk space since you have a local copy of the CVS
tree, plus need space to check the actual source out from CVS.
-------------------------------------------------------------------
Pedro Jos� Lobo Perea Tel: +34 1 336 78 19 Centro de C�lculo
Fax: +34 1 331 92 29 EUIT Telecomunicaci�n - UPM e-mail:
pjlobo@euitt.upm.es
--
Kent S. Gordon
Architect
iNetSpace Co.
voice: (972)851-3494 fax:(972)702-0384 e-mail:kgor@inetspace.com