ty to actually support this new audience and platform. If there is
a large influx of users compounded by problems, I suspect it's again,
going to reflect poorly on the PostgreSQL community.
...just some ramblings
--
Greg Copeland, Owner
[EMAIL PROTECTED]
Copeland Computer Consulting
940.2
e info, but I've already noticed that. XFS is no option since it does
> not work with drbd,
> but jfs seems to be quite good.
>
> Regards,
> Mario Weilguni
>
> ---(end of broadcast)---
> TIP 7: don't forget to
flexibility in your implementation.
At any rate, I agree with the other comments. Maintenance issues are
probably going to be the gotcha if you're not forward looking.
Regards,
Greg Copeland
On Sun, 2003-03-02 at 19:33, Mark Jones wrote:
> > The real question is, the data coll
ecks aren't
> especially useful.
This is exactly why "magic numbers" or simple algorithmic bit patterns
are commonly used. If the "magic number" or bit pattern doesn't match
it's page number accordingly, you know something is wrong. Storage cost
tends to b
27;s the one I used) doesn't do a query
> > backup, but a pages backup. What I mean is that it looks for pages in the
> > system that has changed from the las full backup and backs them up.
> >
> > That's how an incremental backup works. PITR is another thing, which
nclined to limit it to 64. If you do hit a file
> descriptor problem, *you are hosed*.
>
That does seem like a more reasonable upper limit. I would rather see
people have to knowingly increase the limit rather than bump into system
upper limits and start scratching their head
n
> someone modifying the tarballs; our CVS is on that machine too.
>
> ---
>
> Greg Copeland wrote:
> > On Tue, 2003-02-11 at 18:27, Curt Sampson wrote:
> > > On Wed, 11 Feb 2003, Greg Copeland wrote:
> > >
&g
On Tue, 2003-02-11 at 18:27, Curt Sampson wrote:
> On Wed, 11 Feb 2003, Greg Copeland wrote:
>
> > On Wed, 2003-02-05 at 18:53, Curt Sampson wrote:
> >
> > [Re: everybody sharing a single key]
> >
> > This issue doesn't change regardless of the mechanis
s to be used by the OS
as it is suppose to bypass some of the filesystem overhead.
Regards,
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
ng
if the vast majority of people only used PostgreSQL with Apache. I know
I'm using it in environments in which no way relate to the web. I'm
thinking I'm not alone.
Regards,
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
---(end of broa
On Tue, 2003-02-11 at 11:23, mlw wrote:
> Greg Copeland wrote:
>
> >
> >
> >I'd personally rather have people stumble trying to get PostgreSQL
> >running, up front, rather than allowing the lowest common denominator
> >more easily run PostgreSQL on
lk away and claim it performs horribly are probably
doing more harm to the PostgreSQL community than expecting someone to be
able to install software ever can.
Nutshell:
"Easy to install but is horribly slow."
or
"Took a couple of minutes to con
On Wed, 2003-02-05 at 18:53, Curt Sampson wrote:
> On Thu, 5 Feb 2003, Greg Copeland wrote:
>
> > > > > > Who will actually hold the key? Where will it be physically kept?
> > > >
> > > > Good question but can usually be addressed.
> > >
y enough, I am seeing
explicit commits here.
It appears that the benchmarks are attempting to use transactions,
however, I have no idea if MySQL's HEAP supports them. For all I know,
transactions are being silently ignored.
Regards,
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Com
t the quality of the
middleware interface between PHP and PostgreSQL. Does anyone know if we
can rule out some of the performance loss by pinning it to bad
middleware implementation for PostgreSQL?
Regards,
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
h does not provide for authentication and even more importantly,
verification of authentication. These concepts are key to creating a
secure environment.
Regards,
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
On Mon, 2003-02-10 at 21:57, [EMAIL PROTECTED] wrote:
On Tue, 2003-02-04 at 18:27, Curt Sampson wrote:
> On Tue, 2003-02-04 at 16:13, Kurt Roeckx wrote:
> > On Tue, Feb 04, 2003 at 02:04:01PM -0600, Greg Copeland wrote:
> > >
> > > Even improperly used, digital signatures should never be worse than
> > > simple
ht here: can you reduce the MTU on the LAN linking the NFS
> server to the NetBSD box? If so, does it help?
>
Tom,
I'm curious as to why you think adjusting the MTU may have an effect on
this. Lowering the MTU may actually increase fragmentation, lower
efficiency, and even exacerbate
On Wed, 2003-02-05 at 00:22, Curt Sampson wrote:
> On Wed, 4 Feb 2003, Greg Copeland wrote:
>
> > If three people are required to sign a package prior to release,
> > what happens when one of them is unavailable for signing (vacation,
> > hospital, etc). This is one of
On Tue, 2003-02-04 at 16:13, Kurt Roeckx wrote:
> On Tue, Feb 04, 2003 at 02:04:01PM -0600, Greg Copeland wrote:
> >
> > Even improperly used, digital signatures should never be worse than
> > simple checksums. Having said that, anyone that is trusting checksums
> >
al signatures should never be worse than
simple checksums. Having said that, anyone that is trusting checksums
as a form of authenticity validation is begging for trouble. Checksums
are not, in of themselves, a security mechanism. I can't stress this
enough. There really isn't any comparis
> How is verification of the files before signing accomplished?
> >
The person creating the initial package release should also initially
sign it. From there, the web of trust for the people signing it can
work as designed. Once the initial package has been generated, it
should not leave h
on. Then, of course, there is 'ol
snail-mail route too. Of course, nothing beats meeting in person having
valid ID and fingerprints "in hand." ;)
Regards,
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
---(end of broadcast)
gt;
> cjs
And that's the beginning of the web of trust. ;) Worth noting that
snail-mail and phone calls can easily play a role in this process as
well. I think if USPO can play a role in delivering master keys for pin
pads used by banks across America and the around the world, surely i
On Mon, 2003-02-03 at 13:55, Kurt Roeckx wrote:
> On Mon, Feb 03, 2003 at 12:24:14PM -0600, Greg Copeland wrote:
> > On Sun, 2003-02-02 at 20:23, Marc G. Fournier wrote:
> >
> > > right, that is why we started to provide md5 checksums ...
> >
> > md5 check
een signed with a key which can
be readily validated from multiple independent sources.
Regards,
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
package.
I certainly have no problem with people signing my key nor with signing
others as long as we can verify/authenticate each others keys prior.
Regards,
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
On Sat, 2003-02-01 at 00:34, Adam Haberlach wrote:
> On Sat, Feb 01, 2003 at 12:27:31AM -0600, Greg Copeland wrote:
> > On Fri, 2003-01-31 at 14:36, Dave Page wrote:
> > >
> > > I intend to run the tests on a Dual PIII 1GHz box, with 1Gb of Non-ECC
> > > RAM an
On Sat, 2003-02-01 at 00:46, Dann Corbit wrote:
> MySQL for Win32 has no connection whatsoever with anything from Cygwin
> or Mingw
Excellent. Thanks for humoring me. ;)
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
---(end
he window's directories (system,
windows, etc). My point being, just because you didn't find it in the
mysql directory, doesn't mean it wasn't installed system-wide.
Not saying it does or doesn't do this. Just offering something else
that may need to be looked at.
Regards,
gainst the cygwin dll, the application runs in an
"emulated unix environment." To say it's emulated is really too strong
but to say it adds *tons* of overhead certainly won't make you a lair.
;)
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consu
dvocate
it's use, it may not hurt to at least get an understanding of what one
might reasonably expect from it. I'm betting there are people just
waiting to run with FAT32 in the Win32 world. ;)
Regards,
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
in (or equivalent) is being
linked in (statically or dynamically)?
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send &qu
On Fri, 2003-01-31 at 13:04, Kurt Roeckx wrote:
> On Thu, Jan 30, 2003 at 08:21:09PM -0600, Greg Copeland wrote:
> > It doesn't help the
> > confusion that many OS's try to confuse programmers by exposing a single
> > socket interface, etc. Simple fact remains, IPv
On Fri, 2003-01-31 at 13:28, Dave Page wrote:
> > -Original Message-
> > From: Greg Copeland [mailto:[EMAIL PROTECTED]]
> > Sent: 31 January 2003 16:12
> > To: PostgresSQL Hackers Mailing List
> > Subject: [HACKERS] Odd website behavior..
ot; as is the current PostgreSQL/Win32 effort.
Care to expand on exactly what you believe the distinction is? ...or
did I miss the humor boat? :(
Regards,
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
---(end of broadcast)---
he
original.
Just a heads up that something funky is going on. ;)
Regards,
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
s
4 and IPv6 share pretty much a name and
that's about it.
IPv6 has some provisions to help people migrate toward it (from IPv4),
however, IPv6 is a distinctly different protocol. It doesn't help the
confusion that many OS's try to confuse programmers by exposing a single
socket interface
lt that branch to confirm it.
Ouch. Nope, I don't think that's my finger prints. ;)
Greg
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
to support longs (IIRC)? It's been a while now so I
don't recall exactly what got changed. I do remember that I chanced
some test code to ensure it tested the newly fixed data type.
Regards,
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
--
You can easily lose
large amounts of data on NTFS.
You also compared NTFS with ext2. That's not exactly fair. Better you
should compare NTFS with ext3, XFS, JFS, ReiserFS. It's a better, more
fair comparison, as now we're talking about the same category of file
system.
--
Greg C
re
holders of each respective company would come unglued if the largest
software audience in the world were completely ignored.
Simple fact is, your example really is pretty far off from supporting
any view. Bluntly stated, both are in that market because they want to
make money; they're ev
willing to follow up any
> >leads people might have and may even suggest fixes if necessary. I have
> >Bcc'd the engineer on this message and will send anything I get to them.
> >
> >
> >
>
>
>
> ---(end of broadcast)-
Should it be saying, "Temporarily Unavailable"?
Regards,
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-n
On Wed, 2003-01-22 at 23:40, Justin Clift wrote:
> Justin Clift wrote:
> > Greg Copeland wrote:
> >
> >> Have you tried IBM's OSS visualization package yet? Sorry, I don't seem
> >> to recall the name of the tool off the top of my head (Data Explorer??)
le, it's very doubtful that the new thread will show any bias
toward the original thread's CPU. Most modern OS's do run each thread
within a process spread across n-CPUs. Those that don't are probably
attempting to modernize as we speak.
--
Greg Copeland <[EMAIL PROTECTE
ere is anyone here who'd be interested in helping out here.
>
> :-)
>
> Regards and best wishes,
>
> Justin Clift
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Views or C-functions, I think the idea is excellent. It's the concept
that I really like.
Greg
On Mon, 2003-01-13 at 15:00, Dave Page wrote:
> > -Original Message-
> > From: Greg Copeland [mailto:[EMAIL PROTECTED]]
> > Sent: 13 January 2003 20:56
> > To
t_views(), which
> would already be included with each server. One of the reasons that this
> was not feasible in the past was that we needed functions that could
> return multiple rows and columns easily. Now that we have that in 7.3,
> it might be worth revisiting.
>
> Robert Tr
SIGKILL is an appropriate response to
> running out of memory. I cannot offhand think of a more brain-dead
> behavior in any OS living or dead, but that's what it does.
Just FYI, I believe the 2.6.x series of kernels will rectify this
situation.
--
Greg Copeland <[EMAIL
n't understand the problem. The ads are very small and
completely innocuous. Why would anyone care? Who's complaining and
why?
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
On Tue, 2003-01-07 at 12:21, Greg Stark wrote:
> Greg Copeland <[EMAIL PROTECTED]> writes:
>
> > That's the power of using the process model that is currently in use. Should
> > it do something naughty, we bitch and complain politely, throw our hands in
> > the
rld is [EMAIL PROTECTED] ... is that
> a real mailing list, and if so why? It sounds a bit, um, duplicative.
>
> ---(end of broadcast)---
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister
On Tue, 2003-01-07 at 02:00, Shridhar Daithankar wrote:
> On 6 Jan 2003 at 6:48, Greg Copeland wrote:
> > > 1) Get I/O time used fuitfully
> > AIO may address this without the need for integrated threading.
> > Arguably, from the long thread that last appeared on the top
time I touched VMS (about 10 years
> ago) it wasn't all that Unix-like.
>
> :-)
>
> Regards and best wishes,
>
> Justin Clift
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
---(end of broadcast)---
On Mon, 2003-01-06 at 16:17, Bruce Momjian wrote:
> Greg Copeland wrote:
> > On Mon, 2003-01-06 at 15:59, Bruce Momjian wrote:
> > > Greg Copeland wrote:
> > > > > It appears right at the top because creating the socket is the first
> > > > > thing
On Mon, 2003-01-06 at 15:59, Bruce Momjian wrote:
> Greg Copeland wrote:
> > > It appears right at the top because creating the socket is the first
> > > thing it does. A good question is once we have a way for the user to
> > > control IPv4/6, what do we ship as a d
On Mon, 2003-01-06 at 15:43, Bruce Momjian wrote:
> Greg Copeland wrote:
> > On Mon, 2003-01-06 at 15:29, Peter Eisentraut wrote:
> > > (2) A socket type is explicitly enabled for the server to use, and if
> > > creation fails, server startup fails. It seems that the cu
x27;s compiled for IPv6
support but the kernel isn't compiled to support IPv6. If that is the
case, admittedly, you seem to have a point. If someone compiles in v6
support and their system doesn't have v6 support and it's been requested
via run-time config, it's should fail just l
code offering is not much more than a
token in its current form. No offense meant.
After it's all said and done, I'd have to see a lot more meat before I'd
be convinced that threading is ready for PostgreSQL; from both a social
and technological perspective.
res that there are not any localized files or
changes which might become part of a tarball/release which are not
officially part of the repository.
I can't stress enough that a release should never happen unless source
has been tagged. Releases should ALWAYS be made from a
AYS have the power to hose things. Period. As
such, I don't consider that to be a valid argument.
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
---(end of broadcast)---
TIP 2: you can get off a
ly safe. I think that someday, running pg_upgrade
> standalone will become *necessary*, not just a good safety feature.
>
> regards, tom lane
I thought there was talk of adding a "single user"/admin only mode.
That is, where only the administrator can co
or
things like parallel sorts and queries as it relates to a single
backend.
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
On Sat, 2003-01-04 at 04:27, Peter Eisentraut wrote:
> Greg Copeland writes:
>
> > Just a reminder, there still doesn't appear to be a 7.3.1 tag.
>
> There is a long tradition of systematically failing to tag releases in
> this project. Don't expect it to improve
the upgrade problem has a much higher impact to real PostgreSQL sites.
Exactly. Trying to speed up something that shouldn't be in the critical
path is exactly what I'm talking about.
I completely agree with you!
--
Greg Copeland <[EMAIL PROTECTED]>
Copelan
to address this issue. Not only that, but
by definition, it's almost an oxymoron. If you really need high
performance, you shouldn't be using transient connections, no matter how
fast they are. This, in turn, brings you back to persistent connections
or connection pools/caches.
--
l section. It's highly recommend by MS as the majority of Win32
applications expect uniprocessor systems and they are VERY fast. As
soon as multiple processors come into the mix, critical sections become
a HORRIBLE idea if any soft of scalability is desired.
> Is it a FAQ? If not, it ought
where x > y order by foo ;", could be run
on multiple CPUs if the sort were large enough to justify.
After it's all said and done, I do agree that threading just doesn't
seem like a good fit for PostgreSQL.
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
5432
> checking for default soft limit on number of connections... 32
> checking for gcc... no
> checking for cc... no
> configure: error: no acceptable C compiler found in $PATH
>
> Thanks,
>
> Al
>
> ---(end of broadcast)-
lso see a 7.2.3, etc.,
just as one would expect but nothing about 7.3 dot releases.
I'm still getting, "cvs [server aborted]: no such tag REL7_3_1_STABLE".
Something overlooked here?
Regards,
Greg Copeland
On Mon, 2002-12-23 at 09:57, Bruce Momjian wrote:
> Greg Copeland
MAIL PROTECTED]
>
Hmm. For some reason I'm not seeing a 7.3.1 tag in CVS. Do you guys do
something else for sub-releases? Case in point:
cvs [server aborted]: no such tag REL7_3_1_STABLE
It's still early here so I may be suffering from early morning brain
rot. ;)
Regard
PostgreSQL is constantly being improved.
Mind share is a powerful thing and as any advertiser will tell you,
press releases is one of the best ways to get the word out.
Greg
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On Tue, 2002-12-17 at 20:55, Neil Conway wrote:
> On Tue, 2002-12-17 at 21:33, Greg Copeland wrote:
> > I do agree, GBorg needs MUCH higher visibility!
>
> I'm just curious: why do we need GBorg at all? Does it offer anything
> that SourceForge, or a similar
On Tue, 2002-12-17 at 20:07, Alvaro Herrera wrote:
> On Tue, Dec 17, 2002 at 07:43:05PM -0600, Greg Copeland wrote:
> > On Tue, 2002-12-17 at 19:38, Marc G. Fournier wrote:
>
> > > How come these solutions are such well kept secrets? I've heard of
> > > neit
SQL. Of course, I'm not attempting to
assert any true to what I've heard but since it's being talking about,
perhaps someone can clarify how well it REALLY works. Perhaps even
provide some more details on it?
Never heard of QueryMaster. Perhaps someone would like to talk a little
more
Seems I hit the nail on the head. ;)
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
ize it away if
there wasn't an additional read/write access which followed. In other
words, why do what is more or less a no-op if it's never accessed again.
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
al estimates which someone might make to allow for a window of
failure. That is, I don't believe increasing the number of WAL's is
going to satisfactorily address the issue.
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
---(end of bro
c the data. This way it does not matter if
> WAL log is recycled as it is already replicated someplace else..
>
> HTH
>
> Shridhar
>
> -------(end of broadcast)---
> TIP 4: Don't 'kill -9
ry strategy for PITR master-slave
replication should the master fail (assuming hot fail over/backup)? A
simple dump/restore? Are there/is there any facilities in PorstgreSQL
for PITR archival which prevents PITR logs from be recycled (or perhaps,
simply archived off)? What about PITR strea
h 7.3.1. Increment major or minor?
> >
> > Major. I thought you did it already?
>
> I did only minor, which I knew was safe. Do folks realize this will
> require recompile of applications by 7.3 users moving to 7.3.1? That
> seems very drastic, and there have been very few problem re
Perhaps compression should be added to the list of protocol changes.
This way, we can allow for per packet evaluation for compression.
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
On Tue, 2002-12-10 at 21:50, Bruce Momjian wrote:
> Tom Lane wrote:
> > Ian
ON, OFF, or AUTO,
> > meaning it would determine if there was value in the compression and do
> > it only when it would help.
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
one.
> >
> > To be thoroughly amused, read the libtool source. Grep for 'version_type'.
> >
> > --
> > Peter Eisentraut [EMAIL PROTECTED]
> >
> >
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
to use a multiple process AVD right
> now. Imagine m databases on n different drive sets for large production
> databases.
That's right. I always forget about that. So, it seems, regardless of
the namespace effort, we shouldn't be limiting the number of concurrent
AVD's.
DBA can better control
who and what is taking his CPU away (e.g. only that one remote location
being fed via ISDN). If GUC can fully satisfy, I certainly won't argue
against it.
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
d logistical use). An example of this would be to
avoid any compression on trivially sized result sets. Again, this is
another area where I can imagine some tunable parameters.
Just to be on the safe side, I'm cc'ing Josh Drake at Command Prompt
(Mammoth) to see what they can offer up on it
in
> common areas.
>
> Perhaps a more appropriate rule would be 1 AVD per tablespace? Since
> PostgreSQL only has a single tablespace at the moment
But tablespace is planned for 7.4 right? Since tablespace is supposed
to go in for 7.4, I think you've hit the nail on the he
hink that it would be available
for 7.4 of 7.5 time frame.
--
Greg Copeland <[EMAIL PROTECTED]>
Copeland Computer Consulting
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On Fri, 2002-11-29 at 07:19, Shridhar Daithankar wrote:
> On 29 Nov 2002 at 7:59, Matthew T. O'Connor wrote:
>
> > On Thursday 28 November 2002 23:26, Shridhar Daithankar wrote:
> > > On 28 Nov 2002 at 10:45, Tom Lane wrote:
> > > > This is almost certainly a bad idea. vacuum is not very
> > > >
On Fri, 2002-11-29 at 06:59, Matthew T. O'Connor wrote:
> On Thursday 28 November 2002 23:26, Shridhar Daithankar wrote:
> > On 28 Nov 2002 at 10:45, Tom Lane wrote:
> > > "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> > > > interesting thought. I think this boils down to how many knobs do we
pic as it relates to PostgreSQL, it
probably wouldn't be appropriate to followup on the mailing list.
Best Regards,
Greg Copeland
On Wed, 2002-10-30 at 02:19, Dave Page wrote:
>
>
> > -Original Message-
> > From: Greg Copeland [mailto:greg@;copelandconsu
On Fri, 2002-10-25 at 00:52, Marc G. Fournier wrote:
> Ya, I've thought that one through ... I think what I'm more looking at is
> some way of 'limiting' persistent connections, where a server opens n
> connections during a spike, which then sit idle indefinitely since it was
> one fo those 'slashd
Could you use some form of connection proxy where the proxy is actually
keeping persistent connections but your application is making transient
connections to the proxy? I believe this would result in the desired
performance boost and behavior.
Now, the next obvious question...anyone know of any
If you were using them that frequently, couldn't you just keep a
persistent connection? If it's not used that often, wouldn't the
overhead of preparing the query following a new connection become noise?
Greg
On Wed, 2002-10-23 at 09:24, Hans-Jürgen Schönig wrote:
> First of all PREPARE/EXECUTE
On Wed, 2002-10-23 at 08:48, Tom Lane wrote:
> Greg Copeland <[EMAIL PROTECTED]> writes:
> > Okay. I've started looking at plpython to better understand it's memory
> > needs. I'm seeing a mix of mallocs and PLy_malloc. The PLy version is
> > basical
On Tue, 2002-10-22 at 22:28, Tom Lane wrote:
> Greg Copeland <[EMAIL PROTECTED]> writes:
> >So again, I'm not really sure it they are meaningful at
> > this point.
>
> psql might well have some internal leaks; the backend memory-context
> design doesn't app
On Tue, 2002-10-22 at 17:09, Tom Lane wrote:
> Greg Copeland <[EMAIL PROTECTED]> writes:
> > I've started playing a little with Postgres to determine if there were
> > memory leaks running around. After some very brief checking, I'm
> > starting[1] to thin
this done periodically? If so, what tools are others using? I'm
currently using dmalloc for my curiosity.
[1] Not sure yet as I'm really wanting to find culumative leaks rather
than one shot allocations which are simply never freed prior to process
termination.
Regards,
1 - 100 of 228 matches
Mail list logo