On Sat, 7 Apr 2001, Lamar Owen wrote:
> One quick note -- since 'R' < 'b', the RC RPM's must be forced to
> install with --oldpackage, as RPM does a simple strcmp of version
> numbers -- 7.1RC3 < 7.1beta1, for instance. Just force it with
> --oldpackage if you have a 7.1beta RPM already installe
Are up. Contrib subpackage includes built binaries.
Binary RPMset built for _Red_Hat_6.2_. I will be building Red Hat 7.0
RPMS after I get back from a two day vacation -- which will put me back
online Wednesday. I might get a set out for RH7 tomorrow, though.
The split to contrib and docs subp
On Sun, 08 Apr 2001 11:24, Peter Eisentraut wrote:
> Since people suddenly seem to be suffering from bandwidth concerns I
> have devised a new distribution split to address this issue.
[ ... snipping the many tarballs argument ... ]
For me and I expect many other folk on the edge of civiliz
Hi Peter ...
The problem this cycle has been that as soon as a package is ready
for announce, ppl have been cropping up with bugs that need to be fixed,
so we don't bother announcing it ... except to -hackers ...
We are currently at Release Candidate 3, with an RC4 most likely
g
One quick note -- since 'R' < 'b', the RC RPM's must be forced to
install with --oldpackage, as RPM does a simple strcmp of version
numbers -- 7.1RC3 < 7.1beta1, for instance. Just force it with
--oldpackage if you have a 7.1beta RPM already installed.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:
> >> CREATE INDEX hash_i4_index ON hash_i4_heap USING hash (random int4_ops);
> >> + ERROR: cannot read block 3 of hash_i4_index: Bad address
>
> "Bad address"? That seems pretty bizarre.
This is obviously something that shows up on _some_ NetBSD platforms.
The above w
A friend of mine (Matthew Green) mentioned that 7.1RC2 had NetBSD/powerpc
down as unttested, and asked me to test it. So here are the results:
On my NetBSD/macppc system running NetBSD 1.5, gmake check reported that 2
of 62 tests failed. I've attached regression.diff to this message.
The two tha
matthew green <[EMAIL PROTECTED]> writes:
> digging into the regression.diffs, i can see that:
> - reltime failed because it just had:
> ! psql: Backend startup failed
>The postmaster log file should have more info, but a first thought is
>that you ran up against
On Fri, 06 April 2001, Tom Lane wrote:
>
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
> > Try using int2()/int4()/int8() instead of integer().
> >> Why is that NOT documented under "Matematical functions"?
>
> > Because we haven't received any patches to document it? ;)
>
> Or because it's no
Debian packages of 7.1RC3 have been uploaded to the Debian experimental
distribution and are also available at http://www.debian.org/~elphick/postgresq
l
These packages are built for sid (Debian unstable); I am currently
trying to build a set for potato (stable).
Incidentally, when the next re
>> digging into the regression.diffs, i can see that:
>> - reltime failed because it just had:
>> ! psql: Backend startup failed
The postmaster log file should have more info, but a first thought is
that you ran up against process or swap-space limitations. The parallel
Hello all,
I would like to inform you all that I am currently working on the
implementation of PL/pgSQL packages on both server-side (PostgreSQL 7.1)
and client-side (PgAdmin).
The idea is to add an PL/pgSQL Integrated Development Environment to
pgadmin. Help and suggestions needed. If someone
>> i will be reinstalling this SS20 with a full installation sometime in
>> the next few days. i will re-run the testsuite after this to see if
>> that is causing any of the lossage.
Please let us know.
actually, i had a classic i could test with -- all except horology passe
Karl DeBisschop wrote:
> Actually, since you can suppress installation of the docs with --nodocs,
> I would very much prefer to keep the html and text docs in the main RPM.
> Otherwise I have two directories in /usr/doc for one software suite.
I'm researching how to get a subpackage to place docs
On Tue, 3 Apr 2001 14:10:12 -0700, Nathan Myers alluded:
> I saw three separate reports of successful builds on Linux 2.4.2 on x86
> (including mine), but it isn't listed here.
[jeff@cairhien pronto]$ /var/postgresql/bin/psql -V
psql (PostgreSQL) 7.1RC1
contains history support
..
[jeff@ca
"Oliver Elphick" wrote:
>Debian packages of 7.1RC3 have been uploaded to the Debian experimental
>distribution and are also available at http://www.debian.org/~elphick/postgr
>esql
>
>These packages are built for sid (Debian unstable); I am currently
>trying to build a set for pota
No, I was wrong in even mentioning libpgtcl. You don't even need that.
pgmonitor does not connect to the database at any time. I should run as
a shell script if you have tcl/tk >= 8.0 installed.
>
> What I need to do to install libtcl
>
> Do I still need to
> createlang -d dbname pltcl??
> a
We are just (as per other queries recently) building a new system
using postgresql as the backend database. 7.1 seems like it is going
give us a number of essential fixes and useful features that make it
worth waiting a while.
As I have not seen announcements of the beta and RC cuts on
pgsql-anno
Hi!
I've noticed a pg_dump/pg_dumpall problem with timestamp variables, in
dumping the minute, and second values:
instead of dumping
12:01:00.00 it dumps out 12:60:00.00 which is not accepted when
restoring a database...
Gyuro Lehel
---(end of broadcast)---
Uploaded. Please take a look.
ftp://ftp.postgresql.org/pub/dev/test-rpms
There _are_ changes. I will detail the changes for the RC4 RPMset.
Karl's pl/perl changes will go into the next set. pg_dumplo will have a
built binary, to be located in /usr/lib/pgsql/contrib.
--
Lamar Owen
WGCR Intern
Michael Meskes wrote:
>
> On Tue, Apr 03, 2001 at 06:32:25PM +0300, Adriaan Joubert wrote:
> > we had a problem on Alpha that in interfaces/ecpg/lib/typename.c we
> > have
> > HAVE_LONG_INT_64 defined, but not HAVE_LONG_LONG_INT_64. Consequently no
>
> Sure since that means your long int a
What I need to do to install libtcl
Do I still need to
createlang -d dbname pltcl??
and when??
Jie LIANG
St. Bernard Software
10350 Science Center Drive
Suite 100, San Diego, CA 92121
Office:(858)320-4873
[EMAIL PROTECTED]
www.stbernard.com
www.ipinc.com
On Sat, 7 Apr 2001, Bruce Momjian w
>
>Hi EveryBody:
>
>How can i get the structure of a table (Fields names, data types, etc)
try this:
\d table
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddre
> -Original Message-
> From: Mikheev, Vadim [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 04, 2001 3:37 AM
> To: 'Tom Lane'
> Subject: RE: [BUGS] Loosing files after backend crash
>
>
> 1. Indices could be recreated with REINDEX or pg_class could
> be queried
> with seq scan (s
I tried to intall pltcl, but failed when I tried to build a
pltcl.so
it seems hangging on there forever, what's wrong??
su-2.04# cd /work/src/pgsql702/src/pl/tcl/
su-2.04# ls
CVS mkMakefile.tcldefs.sh.in
INSTALL modules
Makefile
Franck Martin wrote:
>
> I have no idea if what I say is true about the PG distribution by PG people, but
> I have noticed than in the rpms of other distros the postgresql-devel rpms do not
> include all the .h files necessary to build PG extensions. For instance the
> rtree.h and itup.h and gist
On Sat, 7 Apr 2001, Peter Eisentraut wrote:
> The Hermit Hacker writes:
>
> > Okay, unless someone can come up with a really good argument *for* why
> > docs has to be included as part of the main tar file,
>
> Because people want to read the documentation.
get postgresql.src.tar.gz
get postgres
You don't need pltcl, just libtcl.
>
> I tried to intall pltcl, but failed when I tried to build a
> pltcl.so
> it seems hangging on there forever, what's wrong??
>
> su-2.04# cd /work/src/pgsql702/src/pl/tcl/
> su-2.04# ls
> CVS mkMakefile.tcldefs.sh.in
> INSTALL
On Sat, 7 Apr 2001, The Hermit Hacker wrote:
>
> Oh, I definitely like this ... and get rid of the *large* file, which will
> save all the mirrors a good deal of space over time ...
>
> On Sun, 8 Apr 2001, Peter Eisentraut wrote:
>
> > Since people suddenly seem to be suffering from bandwidth con
as soon as Peter commits the changes, I'll do up an RC4 with the new
format so that everyone can test it ...
On Sat, 7 Apr 2001, Lamar Owen wrote:
> The Hermit Hacker wrote:
> > Oh, I definitely like this ... and get rid of the *large* file, which will
> > save all the mirrors a good deal of sp
As the subject says, PostgreSQL 7.1RC3 passes 'make check' when built
as a 64 bit application on HP-UX 11.00.
Yes Vince, I've added it to your results page too:
http://www.postgresql.org/~vev/regress/report.php?50
Regards,
Giles
---(end of broadcast)--
The Hermit Hacker wrote:
> Oh, I definitely like this ... and get rid of the *large* file, which will
> save all the mirrors a good deal of space over time ...
You gonna make a set of RC3 or 4 tarballs along these lines to test? I
want to try a build with this split before doing too much else --
Oh, I definitely like this ... and get rid of the *large* file, which will
save all the mirrors a good deal of space over time ...
On Sun, 8 Apr 2001, Peter Eisentraut wrote:
> Since people suddenly seem to be suffering from bandwidth concerns I have
> devised a new distribution split to addres
Since people suddenly seem to be suffering from bandwidth concerns I have
devised a new distribution split to address this issue. I propose the
following four sub-tarballs:
* postgresql-XXX.base.tar.gz3.3 MB
Everything not in one of the ones below.
* postgresql-XXX.opt.tar.gz 1.7 MB
E
Hi!
I had very funny problems with "make install" of the
CVS version. The clue was a bit strange behavior of bash
(/bin/sh is only a link in my debian).
The whole thing is about wildcard expansion: there's an
option called nocaseglob. I never heard of it before,
but this was the cause for th
Hi.
A few weeks (months?) ago I made a patch to the postgres
backend to get back the number of realized moves after
a MOVE command. So if I issue a "MOVE 100 IN cusrorname",
but there was only 66 rows left, I get back not only "MOVE",
but "MOVE 66". If the 100 steps could be realized, then
"MOVE
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> On such a platform it would hardly be possible to detect anything with any
> reliably. A linker that links a program "succesfully" while the program
> really needs more libraries to be runnable isn't very useful.
You're right, of course -- it's a b
Tom Ivar Helbekkmo writes:
> Giles Lean <[EMAIL PROTECTED]> writes:
>
> > It is still necessary to add -ltermcap after -ledit in
> > src/Makefile.global to have functional history editing in psql.
>
> This is a weakness in the configure script: it goes through a loop
> where it tries to link a pr
On Sat, 7 Apr 2001, Peter Eisentraut wrote:
> Thomas Lockhart writes:
>
> > > > The docs are ready for shipment.
> > > Even better ...
> > > Okay, let's let this sit as RC3 for the next week...
> >
> > I'll go ahead and start generating hardcopy, though I understand that it
> > is no longer allo
> Bruce Momjian writes:
>
> > A major issue is that we don't regenerate docs for 7.1.1 or later, so
>
> Sure we do.
>
> > the 7.1 docs carry for all the 7.1.X releases. That would seem to argue
> > for a separate tarball for docs so people don't redownload the docs
> > again for 7.1.1.
I didn
Giles Lean <[EMAIL PROTECTED]> writes:
> It is still necessary to add -ltermcap after -ledit in
> src/Makefile.global to have functional history editing in psql.
This is a weakness in the configure script: it goes through a loop
where it tries to link a program that calls readline() with, in ord
The Hermit Hacker writes:
> those that don't want it, it sames them 2meg of download time ...
Another way to save at least 1 MB of download time would be bzip2'ed
tarballs.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
---(end of broadcast)--
The Hermit Hacker writes:
> On Sat, 7 Apr 2001, Peter Eisentraut wrote:
>
> > The Hermit Hacker writes:
> >
> > > Okay, unless someone can come up with a really good argument *for* why
> > > docs has to be included as part of the main tar file,
> >
> > Because people want to read the documentatio
Bruce Momjian writes:
> A major issue is that we don't regenerate docs for 7.1.1 or later, so
Sure we do.
> the 7.1 docs carry for all the 7.1.X releases. That would seem to argue
> for a separate tarball for docs so people don't redownload the docs
> again for 7.1.1.
>
>
--
Peter Eisentraut
The Hermit Hacker writes:
> Okay, unless someone can come up with a really good argument *for* why
> docs has to be included as part of the main tar file,
Because people want to read the documentation.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
--
Lamar Owen writes:
> We're going to do this at this point in the release cycle? IOW, is
> there going to be an RC4 with this new packaging, or is the first-off
> tarball with new packaging going to be the *final* 7.1 release *raised
> eyebrow*?
>
> I am certainly NOT opposed to doing this -- jus
Tom Lane writes:
> OTOH, if Marc was only thinking of removing the pre-built docs from the
> tarball, I don't object to that. I'm not sure why those weren't
> distributed as separate tarballs from the get-go. I just say that the
> doc sources are part of the source distribution...
Why would yo
Bruce Momjian writes:
> Can we drop TODO.detail from the tarball too? No need to include that,
> I think. The web site has nice links to it now. Uncompressed it is
> 1.314 megs.
You see where this discussion goes? Do we want to go through each file
and argue whether it needs to be distribute
The Hermit Hacker writes:
> At 2Meg, is there a reason why we include any of the docs as part of the
> standard tar ball? It shouldn't be required to compile, so should be able
> to be left out of the main tar ball and downloaded seperately as required
> .. thereby shrinking the distribution to
Thomas Lockhart writes:
> > > The docs are ready for shipment.
> > Even better ...
> > Okay, let's let this sit as RC3 for the next week...
>
> I'll go ahead and start generating hardcopy, though I understand that it
> is no longer allowed into the shipping tarball :(
I'm not speaking about "all
I will save this for 7.2. Thanks.
> The man page for createlang refers to the --echo option, but in fact
> that option does not exist.
>
> This patch implements it and also expands the man page for a couple of
> options that were not documented.
>
> diff -ur postgresql-7.1RC3/doc/src/sgml/ref
The Hermit Hacker wrote:
> On Sat, 7 Apr 2001, Lamar Owen wrote:
> > Just not well-tested for the RPM build environment :-).
> Ya, but you could concievably test that now, without us doign an RC4 ..
> the files are all there :)
So the structure isn't going to change -- just there's not going to
I searched for the error and I have found :
when I execute psql template0
the SIGSEGV is generated when postinit calls RelationPhaseInitializePhase2
in heap_openr with RelationName = pg_am at the return r I have the error.
when I execute psql template1
the SIGSEGV is generated when postinit call
Karl DeBisschop wrote:
> In my experience so far, it is also noticably slower than gzip. It does
> work, and it is available. I have not yet been convinced that the space
> savings is worth the time lost. But ISTM this is a minor point.
The official tarball is gzipped -- the RPM will use that unt
On Sat, 7 Apr 2001, Lamar Owen wrote:
> The Hermit Hacker wrote:
> > there will be an RC4, I'm just waiting to hear back from Peter E as to
>
> Good.
>
> > whether there is anything in the build process we even risk breaking ...
> > we've been doing the whole split thing for the past release or t
The Hermit Hacker wrote:
> there will be an RC4, I'm just waiting to hear back from Peter E as to
Good.
> whether there is anything in the build process we even risk breaking ...
> we've been doing the whole split thing for the past release or two as it
> is (the FreeBSD ports collection using t
On Sat, 7 Apr 2001, Lamar Owen wrote:
> The Hermit Hacker wrote:
> > Okay, unless someone can come up with a really good argument *for* why
> > docs has to be included as part of the main tar file, I'm going to change
> > the distributin generating script so that it generates a .src.tar.gz file
>
The Hermit Hacker wrote:
> Okay, unless someone can come up with a really good argument *for* why
> docs has to be included as part of the main tar file, I'm going to change
> the distributin generating script so that it generates a .src.tar.gz file
> seperate from the .doc.tar.gz file, which will
Thomas Lockhart wrote:
>
> > > OTOH, if Marc was only thinking of removing the pre-built docs from the
> > > tarball, I don't object to that. I'm not sure why those weren't
> > > distributed as separate tarballs from the get-go. I just say that the
> > > doc sources are part of the source distr
Franck Martin wrote:
> I have no idea if what I say is true about the PG distribution by PG people, but
> I have noticed than in the rpms of other distros the postgresql-devel rpms do not
> include all the .h files necessary to build PG extensions. For instance the
> rtree.h and itup.h and gist.h
The man page for createlang refers to the --echo option, but in fact
that option does not exist.
This patch implements it and also expands the man page for a couple of
options that were not documented.
diff -ur postgresql-7.1RC3/doc/src/sgml/ref/createlang.sgml
postgresql-7.1cRC3/doc/src/sgml/r
61 matches
Mail list logo
