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
...
Thomas? Did I miss your patch for the 'WITH TIMEZONE' regression test?
Does anyone else have anything left outstanding that should hold me off
from doing an RC3 tomorrow?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EM
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:
>
For those that want to get in before the rush, I'm going to do an announce
this evenin to -general and -announce ...
Vince, can you make appropriate changes to the WebSite as far as linking
to it is concerned, so that the mirrors pick up the new links also?
Thanks ..
Marc G. Fournier
On Fri, 6 Apr 2001, Vince Vielhaber wrote:
> On Fri, 6 Apr 2001, The Hermit Hacker wrote:
>
> >
> > For those that want to get in before the rush, I'm going to do an announce
> > this evenin to -general and -announce ...
> >
> > Vince, can you make app
On Fri, 6 Apr 2001, Peter Eisentraut wrote:
> The Hermit Hacker writes:
>
> > baring any major blow ups, the only thing we are waiting on is docs ...
>
> The docs are ready for shipment.
Even better ...
Okay, let's let this sit as RC3 for the next week, as soon as someo
On Fri, 6 Apr 2001, Vince Vielhaber wrote:
> On Fri, 6 Apr 2001, The Hermit Hacker wrote:
>
> > On Fri, 6 Apr 2001, Peter Eisentraut wrote:
> >
> > > The Hermit Hacker writes:
> > >
> > > > baring any major blow ups, the only thing we are waiting o
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,
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
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 shrinkin
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
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 ge
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 w
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
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 mi
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 p
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
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
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
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
> >>
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 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 nece
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
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
cr
pgsql
ticket_ticket_id_seq | sequence | 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
> > "
swore I did a 'setenv PGHOST db.hub.org' to get around it, and it
still failed, but now its working ... most confusing :(
But, still, pg_dumpall doesn't appear to accept the -h option in v7.0.3
...
On Tue, 10 Apr 2001, The Hermit Hacker wrote:
>
> No errors, nothing ... here i
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-pgdum
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 si
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 PROTECTED],
[EMAIL PROTECTED]
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 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'
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
On 13 Apr 2001, Trond Eivind [iso-8859-1] Glomsrød wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
>
> > Here is what we've always sent to to date ... anyone have any good ones
> > to add?
> >
> >
> > Addresses : [EMAIL PROTECTED],
> >
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 N
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
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 sys
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
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 th
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 ...
-
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..."
e wishes. I also 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 essentia
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 fa
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 2001
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 fav
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 th
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
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 ...
O
I tried to do a 'kill ' 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
horde
Okay, I *swear* I tried both 'kill ' and 'kill -TERM ' 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 'kil
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
>
>
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 mu
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 installe
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 <
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 l
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'
A
lem);
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
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
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
> >
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
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
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/disabl
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 ever
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
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 an
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 communi
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 ...
> > > >
> > > > *Ma
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, Bruce Momjian wrote:
>
> WAL was a difficult feature to add to 7.1. Currently, it is only used
> as a performance benefit, but I expect it will be used in the future to
> add new features like:
>
> Advanced Replication
How?
> Point-in-time recovery
I thought t
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
> >
> > H
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
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. Fo
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 jus
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*
>
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 convenienc
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
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 yo
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 sen
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-creatab
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
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
> > Cann
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 wit
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
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
WH
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.
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 rel
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 y
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: scrappy@{freeb
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.
On Tue, 29 May 2001, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > The column 'zip' is of type text. As such, indices will not be used except
> > in the case when the where clause is WHERE zip ~ '^' for btree
> > indices.
>
> Uh ... nonsense.
Oh good, I was worried there for a s
Tom, with all the work you've been doing inside planner and optimizer, has
there been anything done for 7.1.2 to make how a query is written cause
the backend to be more intelligent?
I'm playing with a query that I just don't like, since its taking ~3min to
run ...
It started as:
EXPLAIN SELEC
Morning all ...
Build a file with 100k INSERT statements in it, and run psql -f on
that file ... no BEGIN/END in the file, just straight INSERTs ... what is
the max throughput ppl can see?
I'm seeing reports of it maxing out on an AIX around 450, and on
an HP around 380 ... anyo
Morning all ...
Have a client that is running an HP server, specs as follows:
> HP-UX 11.00 HP 9000 L-200, Dual CPU (400MHz - 64 bit),
> OS Disk: 9GB U2W-LVD SCSI, 10K rpm
They are trying to determine whether or not it will be able to
handle their environment, and we're trying
On Wed, 6 Jun 2001, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > The 4m:30s is running one process for 100K inserts ... with two
> > CPUs/processes, it increases the time to process by almost 40% ... ?
>
> Do you mean two processes insertin
Okay, based on 5k records and a "couple of wallclock minutes" being equal
to ~120sec, you are getting 41 inserts/sec?
On Wed, 6 Jun 2001, KuroiNeko wrote:
> > Build a file with 100k INSERT statements in it, and run psql -f on that
> > file ... no BEGIN/END in the file, just straight INSERTs
1 - 100 of 510 matches
Mail list logo
