ftp://ftp.postgresql.org/pub/source/v7.1.2 ...
Just want a second opinion before I announce more publicly ...
Thanks ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary:
broken how? I just connected into it ...
On Tue, 22 May 2001, Karl DeBisschop wrote:
The Hermit Hacker wrote:
ftp://ftp.postgresql.org/pub/source/v7.1.2 ...
Just want a second opinion before I announce more publicly ...
I'd check. But the postgresql ftp site appears to be broken
On Sun, 20 May 2001, Vadim Mikheev wrote:
1. Space reclamation via UNDO doesn't excite me a whole lot, if we can
make lightweight VACUUM work well.
Sorry, but I'm going to consider background vacuum as temporary solution
only. As I've already pointed, original PG authors finally
On Thu, 17 May 2001, Lamar Owen wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wednesday 16 May 2001 19:05, The Hermit Hacker wrote:
On Wed, 16 May 2001, Lamar Owen wrote:
I am loathe to even bring this up, but with two messages today about it,
I am going to be short
On Wed, 16 May 2001, Lamar Owen wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I am loathe to even bring this up, but with two messages today about it, I am
going to be short and sweet:
We don't have a reasonable upgrade path. ASCII dump-install
new-initdb-restore is not a
On Mon, 14 May 2001, Bruce Momjian wrote:
Bruce Momjian wrote:
Can someone tell me what we use indislossy for?
IIRC it means that if you get something by this index you must check
again in the actual data
I think that at least the GIST intarray (actually intset) methods use
Sorry, worst Subject I've ever come up with, but this is one of those I
haven't got a clue how to describe emails ...
Simple query:
SELECT distinct s.gid, s.created, i.title
FROM status s LEFT JOIN images i ON (s.gid = i.gid AND i.active), personal_data
pd, relationship_wanted rw
On Sat, 12 May 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
So why is it counting 12 more images then are actually found/exist:
Hm. Could we see the EXPLAIN output for both of those?
without count:
NOTICE: QUERY PLAN:
Unique (cost=8.66..8.67 rows=1 width=37
On Sat, 12 May 2001, Tom Lane wrote:
Ah, I see it: your join against relationship_wanted isn't unique.
globalmatch=# select count(*) from personal_data pd
globalmatch-# where pd.gid = 17111 AND pd.gender = 0;
count
---
1
(1 row)
globalmatch=# select count(*) from
On Sat, 12 May 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
So that inflates the number of rows coming out of the join by 5.
Okay, then I'm lost ... why wouldn't that show up without the COUNT()? I
doubt doubt your analysis, I just want to understand why ...
You
it is a branch ... for lack of a better way to work it:
symbolic names:
REL7_1_STABLE: 1.106.0.2
REL7_1_BETA: 1.79
REL7_1_BETA3: 1.86
REL7_1_BETA2: 1.86
REL7_1: 1.102
REL7_0_PATCHES: 1.70.0.2
REL7_0: 1.70
REL6_5_PATCHES: 1.52.0.2
On Thu, 10 May 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Isn't this only critical for those that are using it? Does it affect
those that don't use plpgsql?
No, but I think it's pretty critical for those that do ...
So, why not create a quick patch for those
On Thu, 10 May 2001, Bruce Momjian wrote:
Are we releasing tomorrow. I will stamp the CVS STABLE branch tonight
as 7.1.2.
Not that I'm aware of ... I heard mention something about a couple of
fixes, but we *just* put out 7.1.1 ...
If ppl are affected by the bugs, use cvsup and set yoru tag
On Thu, 10 May 2001, Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
I agree with you because the bug is very critical.
Yes, I'd like to get that plpgsql bug fix out as soon as possible.
Isn't this only critical for those that are using it? Does it affect
those that don't use
On Wed, 9 May 2001, Peter Eisentraut wrote:
We did not bump the shared library versions before the 7.1 release.
Maybe we should do this before 7.1.2 goes out.
Ummm ... unless there are any changes that would require someone to
recompile their apps between v7.1.1 and v7.1.2, I don't think so
On Wed, 9 May 2001, Bruce Momjian wrote:
We did not bump the shared library versions before the 7.1 release.
Maybe we should do this before 7.1.2 goes out.
I thought I did that long ago for 7.1, or I should have anyway. I don't
see the commits either. Seems we can't do it in a minor
On Wed, 9 May 2001, Peter Eisentraut wrote:
I'm talking about the minor number. The only thing that effects is
that executables would pick up the new version if they have the old
one in the path as well, no potential problems.
Okay, but, what does that buy you? One overwrites the old
takes Vince a day or two to catch up ... yes, we are officially released,
and Tom just dump'd some major stats changes into HEAD ...
On Mon, 7 May 2001, Tatsuo Ishii wrote:
Does this mean that we have officially released 7.1.1? I could not
find any statements regarding 7.1.1 on the web
This is just a quick announcement that we have now branched off v7.1.x
from the main development tree, and are starting to dive into development
of v7.2 ...
There have been several changes since v7.1 was released, including:
Fix for numeric MODULO operator (Tom)
pg_dump fixes (Philip)
pg_dump
most odd ... its set to start on rebooted, but either it went down on its
own, or didn't ... restarted now, let me know if its not working ...
On Fri, 4 May 2001, Thomas Lockhart wrote:
cvsup -L 2 postgres.cvsup
Parsing supfile postgres.cvsup
Connecting to postgresql.org
Cannot
On Fri, 4 May 2001, Bruce Momjian wrote:
I see by the messages that 7.1.1 is in the final packaging. Anyone know
when it will be released?
Only Marc knows. :-)
Tomorrow aft ... sorry, got tied up with a client finishing his server
move to v7.1 this afternoon, and we hit problems with a
thnks :)
On Fri, 4 May 2001, Bruce Momjian wrote:
OK, I have updated the file dates for a release tomorrow.
On Fri, 4 May 2001, Bruce Momjian wrote:
I see by the messages that 7.1.1 is in the final packaging. Anyone know
when it will be released?
Only Marc knows. :-)
On Mon, 30 Apr 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Does anyone have any outstanding fixes for v7.1.x that they want to see in
*before* we do this release? Any points unresolved that anyone knows
about that we need to look at?
FWIW, I've finished committing
doesn't this defeat the reasons for going to numerics? is there a reason
why its such a difficult thing to do a SELECT oid on pg_database and
pg_class to get this information? that's what I've been doing when I need
to know *shrug*
On Sun, 29 Apr 2001, Bruce Momjian wrote:
First off I just
On Sun, 29 Apr 2001, Bruce Momjian wrote:
doesn't this defeat the reasons for going to numerics? is there a reason
why its such a difficult thing to do a SELECT oid on pg_database and
pg_class to get this information? that's what I've been doing when I need
to know *shrug*
Yes, but
On Sun, 29 Apr 2001, Bruce Momjian wrote:
I don't know the answers to these questions, which is why I'm asking them
... if this is something safe to do, and doesn't break us again, then
sounds like a good idea to me too ...
I was suggesting the symlinks purely for admin convenience. The
On Sun, 29 Apr 2001, Bruce Momjian wrote:
I can even think of a situation, as unlikely as it can be, where this
could happen ... run out of inodes on the file system ... last inode used
by the table, no inode to stick the symlink onto ...
If you run out of inodes, you are going to have
On Sun, 29 Apr 2001, Bruce Momjian wrote:
Yes, I like that idea, but the problem is that it is hard to update just
one table in the file. You sort of have to update the entire file each
time a table changes. That is why I liked symlinks because they are
per-table, but you are right
Okay, maybe this query isn't quite as simple as I think it is, but does
this raise any flags for anyone? How did I get into a COPY? It appears
re-creatable, as I've done it twice so far ...
eceb=# select e.idnumber,e.password from egi e, auth_info a where e.idnumber !=
a.idnumber;
Backend
On Mon, 30 Apr 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Okay, maybe this query isn't quite as simple as I think it is, but does
this raise any flags for anyone? How did I get into a COPY? It appears
re-creatable, as I've done it twice so far ...
eceb=# select
Morning all ...
I'm going to do a broader announcement in a couple of days, but
Oleg and his gang have just finished setting up their Mailing List
Searching software ...
If you go to fts.postgresql.org, it is like night-day as far as
the old searching is concerned ...
Actually, default appears to be the last month worth of messages ... check
your date range :)
On Fri, 27 Apr 2001, Vince Vielhaber wrote:
On Fri, 27 Apr 2001, The Hermit Hacker wrote:
Morning all ...
I'm going to do a broader announcement in a couple of days, but
Oleg and his
On Fri, 27 Apr 2001, Bruce Momjian wrote:
Vince, can you fix the search links to point to this, as far as
the mailing list searches are concerned? docs are still in udmsearch for
now ...
*Major* thanks to Oleg and his group for making this available
to the community ... now
On Fri, 27 Apr 2001, Bruce Momjian wrote:
On Fri, 27 Apr 2001, Bruce Momjian wrote:
Vince, can you fix the search links to point to this, as far as
the mailing list searches are concerned? docs are still in udmsearch for
now ...
*Major* thanks to Oleg and
On Fri, 27 Apr 2001, Bruce Momjian wrote:
We have discussed splitting the tree on May 1 to start 7.2 development.
If no one objects, we will stay with that schedule.
Please see other thread where we are actually discussing this ... if you
have anything to add to that thread please do so ...
On Fri, 27 Apr 2001, Mikheev, Vadim wrote:
Row reuse without vacuum
Yes, it will help to remove uncommitted rows.
Same question as I asked Bruce ... how? :) I wasn't trying to be
fascisious(sp?) when I asked, I didn't realize the two were connected and
am curious as to how :)
On Fri, 27 Apr 2001, Bruce Momjian wrote:
How?
I guess other hosts could read the WAL to find out what changed.
I wonder if that would get around one of the issues I had brought up a
ways back concerning replication and stuff like sequences ...
Row reuse without vacuum
How?
On Fri, 27 Apr 2001, Mikheev, Vadim wrote:
Row reuse without vacuum
Yes, it will help to remove uncommitted rows.
Same question as I asked Bruce ... how? :) I wasn't trying to be
fascisious(sp?) when I asked, I didn't realize the two were
connected and am curious as to
As Tom's mentioned the other day, we're looking at doing up v7.1.1 on
Tuesday, and starting in on v7.2 ...
Does anyone have any outstanding fixes for v7.1.x that they want to see in
*before* we do this release? Any points unresolved that anyone knows
about that we need to look at?
Marc G.
On Thu, 26 Apr 2001, Vince Vielhaber wrote:
On Wed, 25 Apr 2001, The Hermit Hacker wrote:
On Wed, 25 Apr 2001, Vince Vielhaber wrote:
On Wed, 25 Apr 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Autoconf has a 'LOADAVG' check already, so what is so
On Tue, 24 Apr 2001, Nathan Myers wrote:
On Tue, Apr 24, 2001 at 11:28:17PM -0300, The Hermit Hacker wrote:
I have a Dual-866, 1gig of RAM and strip'd file systems ... this past
week, I've hit many times where CPU usage is 100%, RAM is 500Meg free and
disks are pretty much sitting idle
On Wed, 25 Apr 2001, Peter Eisentraut wrote:
Tom Lane writes:
A conncurrent-xacts limit isn't perfect of course, but I think it'd
be pretty good, and certainly better than anything based on the
available load-average numbers.
The concurrent transaction limit would allow you to control
On Wed, 25 Apr 2001, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
The idea behind the load average based approach is
to make the postmaster respect the situation of the overall system.
That'd be great if we could do it, but as I pointed out, the available
stats do not allow
On Wed, 25 Apr 2001, Vince Vielhaber wrote:
On Wed, 25 Apr 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Autoconf has a 'LOADAVG' check already, so what is so problematic about
using that to enabled/disable that feature?
Because it's tied to a GNU getloadavg.c
On Wed, 25 Apr 2001, Tom Lane wrote:
I'm still concerned about portability issues, and about whether load
average is really the right number to be looking at, however.
Its worked for Sendmail for how many years now, and the code is there to
use, with all portability issues resolved for every
Got a query that looks like:
SELECT card_info.main_cat, category_details.sub_cat_flag,count(*)
FROM send0,card_info,category_details
WHERE send0.card_id=card_info.card_id
AND category_details.mcategory='e-cards'
[], int nelem);
DESCRIPTION
How hard would it be to knock up code that, by default, ignores loadavg,
but if, say, set in postgresql.conf:
loadavg = 4
it will just refuse connections?
On Tue, 24 Apr 2001, Peter Eisentraut wrote:
Tom Lane writes:
The Hermit Hacker [EMAIL PROTECTED] writes
On Wed, 25 Apr 2001, Lincoln Yeoh wrote:
At 10:59 PM 23-04-2001 -0700, Nathan Myers wrote:
On Tue, Apr 24, 2001 at 12:39:29PM +0800, Lincoln Yeoh wrote:
Why not be more deterministic about refusing connections and stick
to reducing max clients? If not it seems like a case where you're
Anyone thought of implementing this, similar to how sendmail does it? If
load n, refuse connections?
Basically, if great to set max clients to 256, but if load hits 50 as a
result, the database is near to useless ... if you set it to 256, and 254
idle connections are going, load won't rise
On Mon, 23 Apr 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
sendmail does it now, and, apparently relatively portable across OSs ...
sendmail expects to be root. It's unlikely (and very undesirable) that
postgres will be installed with adequate privileges to read /dev
other then a potential buffer overrun, what would be the problem with:
open(kmem)
read values
close(kmem)
?
I would think it would be less taxing to the system then doing a system()
call, but still effectively as safe, no?
On Mon, 23 Apr 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL
On 23 Apr 2001, Ian Lance Taylor wrote:
Tom Lane [EMAIL PROTECTED] writes:
On Linux and BSD it seems to be more common to put /dev/kmem into a
specialized group kmem, so running postgres as setgid kmem is not so
immediately dangerous. Still, do you think it's a good idea to let an
I tried to do a 'kill pid' like I would have in v7.0.3, doesn't affect
it ... so, how to get rid of idle process that have been sitting around
for a long time, without having to shutdown the database itself?
pgsql 64484 0.0 1.0 15352 10172 p4- ISat08PM 0:00.15 postmaster: hordemgr
Okay, I *swear* I tried both 'kill pid' and 'kill -TERM pid' this
morning before I sent this out .. just tried it again and it worked :(
*shrug*
On Thu, 19 Apr 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
I tried to do a 'kill pid' like I would have in v7.0.3, doesn't
try now?
On Thu, 19 Apr 2001, Peter Eisentraut wrote:
What did you do to the CVS server? It takes hours to update a single
file, half a day to run cvs diff. This has been like that for about 48
hours.
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
I can't seem to get at the original anymore, but we talked to Dr.
Soparkar, and is posted a 'followup' of the article to:
http://linuxtoday.com/news_story.php3?ltsn=2001-04-16-009-21-PS-EL-HE-0038
Since I can't seem to get to the original on dqindia.com, I can't comment
on what's changed ...
On Tue, 17 Apr 2001, Tom Lane wrote:
David George [EMAIL PROTECTED] writes:
I just built the postgresql 7.1 final and the configure script is still
checking for sfio. Not a major big deal, but I need to remove the sfio
check from configure.in, run autoconf, and then configure to fix it.
On Sun, 15 Apr 2001, Thomas Lockhart wrote:
Do we need to start thinking about an RPM mailing list? Seems there is
lots of traffic.
The delete key is your friend. So is procmail, if you just can't stand
to see the letters "R", "P", and "M" too close together ;)
I'm not a big fan of the
So, to sum up ... the article did a good job of representing Great Bridge,
did a great injustice (a slap in the face, so to say) to the PostgreSQL
community as a whole, so Great Bridge has no intention of correcting the
situation?
Just to clarify your position, of course ...
On Sun, 15 Apr
On Sat, 14 Apr 2001, Nathan Myers wrote:
This is probably a good time to point out that this is the _worst_
_possible_ response to erroneous reportage. The perception by readers
will not be that the reporter failed, but that PostgreSQL advocates
are rabid weasels who don't appreciate
the thing that pissed me off the most, and set me off, was the totally
blatant errors ... we've had other articles written, with a GB slant to
them, that didn't get my feathers in a ruffle ... the fact that they
*talked* with GB, got quotes from them and some of their partners, and
*still* got
Just as an FYI for those considering the shift ... I just upgraded all of
my databases over to v7.1 from v7.0.3 and it was smooth as silk. The only
problems were having to compile and load a few modules from contrib that
some of my clients were using ...
Took about an hour and a half to do 100
If someone wants to come up with an idea for name, i think that the whole
Win camp could be seperated also ...
pgsql-windows and pgsql-rpm ?
as far as newsgroups are concerned, they would both fall under ports:
comp.databases.postgresql.ports.linux.rpm
comp.databases.postgresql.ports.windows
77 databases in data/base directory ... all number'd ...
select * from pg_database;
doesn't give me the reference to which directory is which database ... so
what table do we need to join on to get this information?
thanks ...
Marc G. Fournier ICQ#7615664 IRC
On Sat, 14 Apr 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
If someone wants to come up with an idea for name, i think that the whole
Win camp could be seperated also ...
pgsql-windows and pgsql-rpm ?
A windows list seems like a good idea. But I'm not sure
On Sat, 14 Apr 2001, Peter Eisentraut wrote:
Bruce Momjian writes:
Do we need to start thinking about an RPM mailing list? Seems there is
lots of traffic.
The traffic naturally peaks around release time, and this time
especially because yours truly messed up the whole build system that
d'oh, should have extended my query ...
select oid,* from pg_database;
gives the directory name ...
thanks :)
On Sat, 14 Apr 2001, Bruce Momjian wrote:
77 databases in data/base directory ... all number'd ...
select * from pg_database;
doesn't give me the reference to which
On Sat, 14 Apr 2001, Peter Eisentraut wrote:
The Hermit Hacker writes:
I like Lamar's suggestion of pgsql-cygwin though ... sound reasonable?
We have pgsql-ports, which isn't seeing too much traffic as it is. Seems
like the cygwin people hang out there anyway.
Ya, well, there is alot
On Sat, 14 Apr 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
I like Lamar's suggestion of pgsql-cygwin though ... sound reasonable?
Yes, that's probably better than pgsql-windows ...
Done ...
---(end of broadcast
there is little, to nothing, factual about that whole article ...
"Great Bridge essentially gives away its open-source database application
at little cost..."
- thannk god I can get it completely for free, eh?
"Great Bridge executives say their licensing costs for the software..."
sent
it to the editor of that rag.
Vince.
On Sun, 15 Apr 2001, The Hermit Hacker wrote:
there is little, to nothing, factual about that whole article ...
"Great Bridge essentially gives away its open-source database application
at little cost..."
- thannk god
Well folks, I just fixed the CVS tags (renamed REL7_1 to REL7_1_BETA and
moved REL7_1 to today) and packaged up the release ... this is it, any new
fixes go into v7.1.1 ... :)
I'm preparing a formal PR/Announce, and will send that out later on this
evening, but want to give some of the mirror
On Fri, 13 Apr 2001, Bruce Momjian wrote:
Here is what we've always sent to to date ... anyone have any good ones
to add?
Addresses : [EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
email added, thanks ...
On 13 Apr 2001, Matthew Rice wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Here is what we've always sent to to date ... anyone have any good ones
to add?
I think that this is still the moderator's address for comp.os.linux.announce:
[EMAIL PROTECTED
Freshmeat updated, Linuxtoday bookmarked ... thanks ;)
On 13 Apr 2001, Trond Eivind [iso-8859-1] Glomsrød wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
On 13 Apr 2001, Trond Eivind [iso-8859-1] Glomsrød wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Here is what we've
Theoretically, should one be able to do:
pg_dumpall db.out
remove 7.0.3 bin, lib, data, etc
install 7.1 bin, lib, etc
initdb 7.1
psql template1 db.out
Basically, has anyone actually tried *that* yet and can report on whether
or not it works?
I'm just about to try it here, on 2gig of data,
v7.0.3 database:
trends_acctng=# \d
List of relations
Name | Type | Owner
-+---+---
accounts| table | pgsql
admin | table | pgsql
calls | table | pgsql
comments| table | pgsql
cookies | table | pgsql
credit_card | table | pgsql
| pgsql
ticket_times | table| pgsql
(34 rows)
neat ...
On Tue, 10 Apr 2001, Joel Burton wrote:
On Tue, 10 Apr 2001, The Hermit Hacker wrote:
all I did was use pg_dumpall from v7.0.3 to dump to a text file, and
"psql template1 dumpfile" to load it bac
On Wed, 11 Apr 2001, Peter Eisentraut wrote:
The Hermit Hacker writes:
okay, not sure how we should document this, but apparently pg_dumpall
doesn't work as the man page at:
http://www.postgresql.org/users-lounge/docs/7.0/user/app-pgdumpall.htm
appears to suggest:
Now, I swore I
On Mon, 9 Apr 2001, Henshall, Stuart - WCP wrote:
When I downlaod a full tarball I want it all, I'm greedy like that.
;)
If it is to be split up as standard I believe problems will arise with
different versions being used together (by me most likley...). Also IMHO it
will not
After v7.1 is released ... ?
On Mon, 9 Apr 2001, Peter Eisentraut wrote:
Excessively long values are currently silently truncated when they are
inserted into char or varchar fields. This makes the entire notion of
specifying a length limit for these types kind of useless, IMO. Needless
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 installed.
On Sun, 8 Apr 2001, Oliver Elphick wrote:
The Hermit Hacker wrote:
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
On Sun, 8 Apr 2001, Peter Eisentraut wrote:
I wrote:
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
*
On Sun, 8 Apr 2001, Oliver Elphick wrote:
The Hermit Hacker wrote:or development:
That means the final release of 7.1 will be called 7.2. Bugfix releases
will then be 7.2.x. Meanwhile new development versions will be 7.3.x
which will finally be released as 7.4, and so
this only represents since 8:30am this morning ...
/source/v7.0.3/postgresql-7.0.3.support.tar.gz = 9
/source/v7.0.3/postgresql-7.0.3.test.tar.gz = 3
/source/v7.0.3/postgresql-7.0.3.docs.tar.gz = 10
/source/v7.0.3/postgresql-7.0.3.tar.gz = 22
/source/v7.0.3/postgresql-7.0.3.base.tar.gz = 9
on
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
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
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, 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
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
On Fri, 6 Apr 2001, Thomas Lockhart wrote:
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 :(
At 2Meg, is there
On Fri, 6 Apr 2001, Bruce Momjian wrote:
On Fri, 6 Apr 2001, Thomas Lockhart wrote:
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
On Fri, 6 Apr 2001, Tom Lane wrote:
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
On Fri, 6 Apr 2001, Bruce Momjian wrote:
That strikes me as an awfully web-centric view of things. Not everyone
has an always-on high-speed Internet link.
If you want to make the docs and TODO.detail be a separate chunk of the
split distribution, that's fine with me. But I don't
Okay, unless I hear different from anyone out there, I'm goin to roll RC3
when I get to work tomorrow, and announce it before I leave (to give it
some time to propogate to the mirrors) ...
On Thu, 5 Apr 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Thomas? Did I miss
I packaged up an RC2 over the weekend, and pretty much as soon as I had it
packaged and in place, before I could announce it, there were several
patches thrown in ... so, I left it there, let anyone who happened to see
it pick it up, but didn't announce it ...
Everything has been quiet, as far
On Wed, 4 Apr 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Everything has been quiet, as far as patches are concerned, for the past
24+hrs ... I'd like to roll (and actually announce) an solid RC3 tonight,
with announce first thing tomorrow morning, unless anyone has
On Wed, 4 Apr 2001, Mikheev, Vadim wrote:
Everything has been quiet, as far as patches are concerned,
for the past 24+hrs ... I'd like to roll (and actually announce)
an solid RC3 tonight, with announce first thing tomorrow morning,
unless anyone has anythign they aer sitting on?
We
On Wed, 4 Apr 2001, Thomas Lockhart wrote:
I've got patches for the regression tests to work around the "time with
time zone" DST problem. Will apply to the tree asap, and will post a
message when that is done.
Sounds cool ... I'll scheduale an RC3 then, around that bug being fixed
...
101 - 200 of 403 matches
Mail list logo
