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
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 distribution...
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
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:
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 the
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 until
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
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 be
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
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 "allowed",
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
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 distributed?
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 you
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/
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
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 order,
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't know
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 allowed into the
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 program that
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 bug
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
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
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
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 address
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 --
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
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 space
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 concerns I
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, 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
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
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
-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 (something
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
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 and not
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
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
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
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
..
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
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 passed,
so
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
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
check
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 not a
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
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
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 was on
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
"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 potato
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
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
51 matches
Mail list logo
