of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
--
Greg Copeland [EMAIL PROTECTED]
Copeland Computer Consulting
---(end of broadcast)---
TIP 6: Have you searched our
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 and a 20Gb (iirc) IDE disk. I will run on Windows
signed and
can reasonably verify that the signing key is safe and/or can be
verified, confidence should be high in the signed 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
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
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 checksums only validate that the intended package
across America and the around the world, surely it's
good enough to help propagate key information for signing packages.
Regards,
--
Greg Copeland [EMAIL PROTECTED]
Copeland Computer Consulting
---(end of broadcast)---
TIP 4: Don't 'kill -9
. 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)---
TIP 6: Have you searched our list archives?
http
generated, it
should not leave his eyes until it has been signed.
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
are not, in of themselves, a security mechanism. I can't stress this
enough. There really isn't any comparison here. Please stop comparing
apples and oranges. No matter how hard you try, you can not make orange
juice from apples.
Regards,
--
Greg Copeland [EMAIL PROTECTED]
Copeland Computer
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
as a form of authenticity validation
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 the reasons why having a single
,
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 the situation.
Is this purely a diagnostic suggestion?
Regards,
--
Greg Copeland [EMAIL PROTECTED]
Copeland Computer
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 checksums. Having said that, anyone
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:
-BEGIN PGP SIGNED
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
---(end of broadcast
,
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 Computer Consulting
---(end of broadcast)---
TIP 2: you can get off all lists
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.
It can be addressed, but how well? This is another big issue that I
. ;)
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 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 only to be disappointed with it and move on.
After it's
relate to the web. I'm
thinking I'm not alone.
Regards,
--
Greg Copeland [EMAIL PROTECTED]
Copeland Computer Consulting
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command
/mapped via pagefile. This is the preferred means of memory
mapped files unless you have a specific need which dictates otherwise.
Meaning, it allows for many supposed optimizations to be used by the OS
as it is suppose to bypass some of the filesystem overhead.
Regards,
--
Greg Copeland [EMAIL
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 mechanism you pick. Anyone
that is signing a key must take
rather see
people have to knowingly increase the limit rather than bump into system
upper limits and start scratching their heads trying to figure out what
the heck is going on.
--
Greg Copeland [EMAIL PROTECTED]
Copeland Computer Consulting
---(end of broadcast
.
---
Greg Copeland wrote:
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
. :-)
I do imagine for some people it will register high on their list.
--
Greg Copeland [EMAIL PROTECTED]
Copeland Computer Consulting
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail
pattern doesn't match
it's page number accordingly, you know something is wrong. Storage cost
tends to be slightly and CPU overhead low.
I agree with you that a CRC is seems overkill for little return.
Regards,
--
Greg Copeland [EMAIL PROTECTED]
Copeland Computer Consulting
On Tue, 2002-06-18 at 09:07, Jan Wieck wrote:
Dann Corbit wrote:
The startup stuff for PostgreSQL is just a few files. It does not seem
insurmountable to change it. But it is none of my business. If it is a
major hassle (for reasons which I am not aware) then I see no driving
Interesting results. You didn't really offer much in how your system
was configured to use the ramdisk. Did you use it to simply store a
database on it? Was the entire database able to fit into available
memory even without the RAMDISK? Did you try only storing indicies on
the RAMDISK? There
Seems the CVS server is not working correctly. I just deleted my CVS
tree and did a fresh checkout of the pgsql module. Everything seemingly
went well. After the check out completed, I did:
[gcope@mouse pgsql]$ ./configure --with-tcl --with-java --with-python
--with-perl
checking build
Looks like I replied to the wrong thread...here's a repeat...
Seems the CVS server is not working correctly. I just deleted my CVS
tree and did a fresh checkout of the pgsql module. Everything seemingly
went well. After the check out completed, I did:
[gcope@mouse pgsql]$ ./configure
this), so by the time you
receive, a checkout should grab the right structures ...
Let me know if it works now for you ...
On 1 Aug 2002, Greg Copeland wrote:
Seems the CVS server is not working correctly. I just deleted my CVS
tree and did a fresh checkout of the pgsql module. Everything
On Thu, 2002-08-01 at 22:39, Curt Sampson wrote:
On 1 Aug 2002, Greg Copeland wrote:
For some reason,
many of the developers are under the impression that even if code is
never touched, it has a very high level of effort to keep it in the code
base. That is, of course, completely
On Tue, 2002-07-30 at 14:54, Hannu Krosing wrote:
On Tue, 2002-07-30 at 16:00, Curt Sampson wrote:
On 30 Jul 2002, Hannu Krosing wrote:
On Tue, 2002-07-30 at 14:51, Adrian 'Dagurashibanipal' von Bidder wrote:
Bruce Momjian:
It causes too much complexity in other parts of the
On Thu, 2002-08-01 at 23:30, Tom Lane wrote:
Greg Copeland [EMAIL PROTECTED] writes:
I seem to find this argument a lot on the list here. For some reason,
many of the developers are under the impression that even if code is
never touched, it has a very high level of effort to keep
On Wed, 2002-07-31 at 22:20, Bruce Momjian wrote:
I am wondering why we even want to specify the WAL location anywhere
except as a flag to initdb. If you specify a location at initdb time,
it creates the /xlog directory, then symlinks it into /data.
Does this have any negative implications
On Fri, 2002-08-02 at 13:46, Thomas Lockhart wrote:
I am wondering why we even want to specify the WAL location anywhere
except as a flag to initdb. If you specify a location at initdb time,
it creates the /xlog directory, then symlinks it into /data.
Does this have any negative
On Sat, 2002-08-10 at 00:25, Mark Kirkwood wrote:
Ralph Graulich wrote:
Hi,
just my two cents worth: I like having the files sized in a way I can
handle them easily with any UNIX tool on nearly any system. No matter
wether I want to cp, tar, dump, dd, cat or gzip the file: Just keep it
.
---
Greg Copeland wrote:
Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
Well, that certainly appeared to be very straight forward. pg.py and
syscat.py scripts were both modified. pg.py
. IMO, any known buffer overrun is worthy of an emergency fix
and corresponding advisory.
Greg Copeland
On Sun, 2002-08-11 at 12:09, Tom Lane wrote:
Justin Clift [EMAIL PROTECTED] writes:
Am I understanding this right:
- A PostgreSQL 7.2.1 server can be crashed if it gets passed certain
On Mon, 2002-08-12 at 00:29, Hannu Krosing wrote:
On Mon, 2002-08-12 at 11:52, Curt Sampson wrote:
On Sun, 11 Aug 2002, Don Baccus wrote:
[snip]
But anyway, I have no particularly huge objection to syntatic sugar
alone. I do have objections to it when it's not saving much typing. (It
is
On Mon, 2002-08-12 at 09:39, Andrew Sullivan wrote:
On Sat, Aug 10, 2002 at 09:21:07AM -0500, Greg Copeland wrote:
I'm actually amazed that postgres isn't already using large file
support. Especially for tools like dump.
Except it would only cause confusion if you ran such a program
On Mon, 2002-08-12 at 10:30, Andrew Sullivan wrote:
On Mon, Aug 12, 2002 at 10:15:46AM -0500, Greg Copeland wrote:
If by turn...on, you mean recompile, that's a horrible idea IMO.
Ah. Well, that is what I meant. Why is it horrible? PostgreSQL
doesn't take very long to compile
On Mon, 2002-08-12 at 11:04, Andrew Sullivan wrote:
On Mon, Aug 12, 2002 at 11:44:24AM -0400, Lamar Owen wrote:
keep discussing the issues involved, and I'll see what comes of it. I don't
have an direct experience with the largefile support, and am learning as I go
with this.
I do
On Mon, 2002-08-12 at 10:39, Oliver Elphick wrote:
On Mon, 2002-08-12 at 15:00, Greg Copeland wrote:
How exactly would you create an abstract base class for table type?
CREATE TABLE abstract_base (
cols ...,
CONSTRAINT No data allowed in table abstract_base! CHECK (1 = 0
On Mon, 2002-08-12 at 11:40, Andrew Sullivan wrote:
On Mon, Aug 12, 2002 at 11:07:51AM -0500, Greg Copeland wrote:
Many reasons. A DBA is not always the same thing as a developer (which
means it's doubtful he's even going to know about needed options to pass
-- if any
On Mon, 2002-08-12 at 11:48, Andrew Sullivan wrote:
On Mon, Aug 12, 2002 at 11:17:31AM -0500, Greg Copeland wrote:
[snip]
There are, in any case, _lots_ of problems with these large files.
All of those are SA issues.
So is compiling the software correctly, if the distinction has
On Sun, 2002-08-11 at 21:15, Christopher Kings-Lynne wrote:
Not a problem. I would rather them be correct.
Worth noting that the first patch is what attempts to fix the long -
int overflow issue. The second patch attempts to resolve attisdropped
column use issues with the python
On Mon, 2002-08-12 at 20:34, Curt Sampson wrote:
Ok, big bundled up reply here to various people.
From: Greg Copeland [EMAIL PROTECTED]
What makes things more confusing is poor understanding of a feature, not
the feature itself.
Agreed. Just because a feature may not be well
On Mon, 2002-08-12 at 18:41, Martijn van Oosterhout wrote:
On Mon, Aug 12, 2002 at 11:30:36AM -0400, Andrew Sullivan wrote:
The problem is not just a system-level one, but a filesystem-level
one. Enabling 64 bits by default might be dangerous, because a DBA
might think oh, it supports
On Mon, 2002-08-12 at 23:09, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, seeing as no one voted, and only Tom and I objected originally, we
will keep the code as Thomas has applied it, namely that PGXLOG/-X is
recognized by initdb, postmaster, postgres, and pg_ctl.
We
.
Requiring soft links also doesn't strike me as a good portable idea
either...not to mention I've been bitten by them before too.
Sign,
Greg Copeland
signature.asc
Description: This is a digitally signed message part
On Tue, 2002-08-13 at 00:33, Curt Sampson wrote:
On Mon, 12 Aug 2002, Don Baccus wrote:
Give it up. You're acting like a turkey. If you aren't, skin yourself
a new non-turkey skin.
Since he appears not to be able to avoid abusive ad hominem attacks,
I'm now sending mail with [EMAIL
On Tue, 2002-08-13 at 00:16, Curt Sampson wrote:
I will revise my opinion the instant someone shows me something that I
can't do relationally, or is easy to implement with inheritance, and
difficult with relational methods. Now you know what you need to do, and
if you have no example, we can
On Tue, 2002-08-13 at 08:15, Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
I think Tom is on to something here. I meant to ask but never got
around to it. Why would anyone need to move the XLOG after you've
inited the db?
I just determined that disk I/O is terrible, so
On Tue, 2002-08-13 at 12:45, [EMAIL PROTECTED] wrote:
On Tue, Aug 13, 2002 at 01:04:02PM -0400, Tom Lane wrote:
On a system where building with large-file support is reasonably
standard, I agree that PG should be built that way too. Where it's
not so standard, I agree with Andrew
On Tue, 2002-08-13 at 12:04, Tom Lane wrote:
On a system where building with large-file support is reasonably
standard, I agree that PG should be built that way too. Where it's
not so standard, I agree with Andrew Sullivan's concerns ...
Agreed. This is what I originally asked for.
Greg
such a
description.
4. Thus, we are in other messages here trying to work out the
model and come up with such a description.
5. The people working this out at the moment appear to be me,
Greg Copeland and Hannu Krosing.
OK, great summary. Isn't the bottom-line
to help spell this out?
Regards,
Greg Copeland
signature.asc
Description: This is a digitally signed message part
? Hmmm...I might have to go do
some reading to find out one way or anther... ;)
Sign,
Greg Copeland
signature.asc
Description: This is a digitally signed message part
On Wed, 2002-08-14 at 10:17, Ross J. Reedstrom wrote:
On Wed, Aug 14, 2002 at 09:39:06AM -0500, Greg Copeland wrote:
I completely agree. This is why I want/wanted to pursue the theory and
existing implementations angle.
In theory, it sounds like a good idea. In practice ... ;-)
LOL
that DB2 can do this for us, and IBM is giving us
the resources to make this transition successful. You can read the
press release here:
http://www.vasoftware.com/news/press.php/2002/1070.html
Sign,
Greg Copeland
signature.asc
Description: This is a digitally signed message part
for all replication implementations may be worthwhile.
That way, no matter what replication method/tool is being used, as long
as it conforms to the defined replication interfaces, generic monitoring
tools can be used to keep an eye on things.
Think this has any merit?
Greg Copeland
follow up, can we assume that he agrees? In not, please
let me know and I'll resubmit patch #2.
In the mean time, patches #1 and #3 should be good to go. Bruce, feel
free to apply those whenever time allows.
Thanks,
Greg Copeland
On Mon, 2002-08-12 at 18:33, Rod Taylor wrote:
All
-Original Message-
From: Greg Copeland [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 15 August 2002 11:09 AM
To: Rod Taylor
Cc: Christopher Kings-Lynne; Bruce Momjian; PostgresSQL Hackers Mailing
List
Subject: Re: [HACKERS] python patch
Well, I tend to agree
wrote:
Greg Copeland [EMAIL PROTECTED] writes:
... it occurred to me that a predefined set of views
and/or tables for all replication implementations may be worthwhile.
Do we understand replication well enough to define such a set of views?
I sure don't ...
regards
On Thu, 2002-08-15 at 09:47, Andrew Sullivan wrote:
On Wed, Aug 14, 2002 at 10:15:32PM -0500, Greg Copeland wrote:
That way, no matter what replication method/tool is being used, as long
as it conforms to the defined replication interfaces, generic monitoring
tools can be used to keep
a generic interface to *monitor* be a waste
of time? In what way would that prevent someone from producing a
*readlly good* replication implementation? I utterly fail to see the
connection.
Regards,
Greg Copeland
signature.asc
Description: This is a digitally signed message part
As I said -- I don't really see the need for a bunch of replication
implementations, and therefore I don't see the need for a generic API
to make the whole mess (slightly) more manageable.
I see. So the intension of the core developers is to have one and only
one replication solution?
Greg
,
Greg Copeland
signature.asc
Description: This is a digitally signed message part
Dang it...meant to mention that the other day when I was working on
those python patches. I had to place tick marks (single quote) around
the number and it was converted correctly.
gcope=# insert into a values ( 99 ) ;
ERROR: column a is of type 'bigint' but expression is of type
documents. While I can see that some specifications are set
in stone, I certainly am not so bold as to assert my crystal ball even
came with batteries. ;) That is, I assume some level of revision to an
initial specification would be required following real-world use.
Regards,
Greg Copeland
feeling is, that's
more and an architectural/design issue rather than a fundamental issue
with the concept.
--Greg Copeland
signature.asc
Description: This is a digitally signed message part
stability and reliability is very important
to them. Perhaps their mantra is the rule of thumb outlined above.
Sign,
Greg Copeland
signature.asc
Description: This is a digitally signed message part
data. While that's true, data can be
restored. It also requires a different personality type. Many people
would be willing to DoS a system, however, that doesn't have to mean
they are willing to destroy data.
Regards,
Greg Copeland
signature.asc
Description: This is a digitally
On Tue, 2002-08-20 at 18:40, Mark Pritchard wrote:
On Tue, 20 Aug 2002 23:48, Greg Copeland wrote:
On Tue, 2002-08-20 at 00:35, Dann Corbit wrote:
Most computer virus problems are caused by buffer overrun. Someone
decided it wasn't very important.
This is true. IMO, it is extremely
On Tue, 2002-08-20 at 19:59, [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Greg Copeland) wrote
At some point in time, you have to stand and say, the buck stops here.
I agree here, but at the same time you cannot put 100% of the
responsibility on the developers. If you are the dba
to such a
concept? Perhaps different types of table inheritance can be considered
in our model...has-a, is-a, etc...
Regards,
Greg Copeland
signature.asc
Description: This is a digitally signed message part
On Thu, 2002-09-05 at 15:51, Hannu Krosing wrote:
On Fri, 2002-09-06 at 03:19, Greg Copeland wrote:
What about the concept of columns being public or private? That is,
certain columns may not be inherited by a child? Any thought to such a
concept? Perhaps different types of table
On Fri, 2002-09-06 at 07:53, Hannu Krosing wrote:
On Fri, 2002-09-06 at 09:53, Curt Sampson wrote:
This looks like a classic case of incorrect modelling to me. Does the
good itself change when it becomes a campaign_good? No. The price
changes, but that's obviously not an integral part of
On Fri, 2002-09-06 at 08:57, [EMAIL PROTECTED] wrote:
On Fri, 2002-09-06 at 07:37, Curt Sampson wrote:
On 5 Sep 2002, Hannu Krosing wrote:
To elaborate on Gregs example if you have table GOODS and under it a
table CAMPAIGN_GOODS then you may place a general overridable constraint
On Fri, 2002-09-06 at 11:05, [EMAIL PROTECTED] wrote:
Oops! [EMAIL PROTECTED] (Greg Copeland) was seen spray-painting on a wall:
That's a pretty forcible constraint. :-).
=20
Is there something broken with your mailer? It's reformatting quotes
rather horribly...
Hmm...not that I know
Does anyone know if such effort is also required to pl/python to become
schema aware?
Regards,
Greg Copeland
On Wed, 2002-09-11 at 19:24, Bruce Momjian wrote:
Patch applied. Thanks.
---
Joe Conway
I think Marc made a pretty good case about the use of command line
arguments but I think I have to vote with Tom. Many of the command line
arguments you seem to be using do sorta make sense to have for easy
reference or to help validate your runtime environment for each
instance. The other side
Well, you'll probably want to pass in a valid timeval structure if you
don't want it to block.
Basically, that snippet tells select on the list of sockets, looking for
sockets that have data to be read while waiting forever. That means it
will block until something appears on one of the sockets
Ensure you don't have termination issues. Make sure your SCSI interface
is configured correctly for your SCSI environment, especially on matters
of termination. Make sure you have enough power to your drive and if
possible, make sure your drives are hung off of distinct power segments
coming
I'll try to have a look-see by the end of the weekend. Any code that
can reproduce it or is it ANY code that uses SPI?
Greg
On Fri, 2002-09-20 at 11:39, Peter Eisentraut wrote:
Tom Lane writes:
On looking a little more closely, it's clear that pltcl_SPI_exec()
should be, and is not,
Well, it looks like it was already taken to the mat.
;)
Greg
On Thu, 2002-09-19 at 16:58, Joe Conway wrote:
Nigel J. Andrews wrote:
On Thu, 19 Sep 2002, Joe Conway wrote:
I can give it a shot, but probably not until the weekend.
I haven't really followed this thread closely, and don't
Just curious, and honestly I haven't looked, but is there any form of
compression between clients and servers? Has this been looked at?
Greg
signature.asc
Description: This is a digitally signed message part
with low bandwidth connectivity to their
servers or where bandwidth may already be at a premium.
The zlib exploit posting got me thinking about this.
Greg
On Thu, 2002-03-14 at 12:20, Bruce Momjian wrote:
Greg Copeland wrote:
Just curious, and honestly I haven't looked, but is there any form
On Thu, 2002-03-14 at 13:35, Bruce Momjian wrote:
Greg Copeland wrote:
Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
Well, it occurred to me that if a large result set were to be identified
before transport between a client and server, a significant amount
On Thu, 2002-03-14 at 14:14, Neil Conway wrote:
On Thu, 2002-03-14 at 14:35, Bruce Momjian wrote:
Greg Copeland wrote:
Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.
Well, it occurred to me that if a large result set were to be identified
before
On Thu, 2002-03-14 at 14:29, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
This may be of value for users with low bandwidth connectivity to their
servers or where bandwidth may already be at a premium.
But don't slow links do the compression themselves, like PPP over a
On Thu, 2002-03-14 at 14:03, Arguile wrote:
[snip]
I'm sceptical of the benefit such compressions would provide in this setting
though. We're dealing with sets that would have to be compressed every time
(no caching) which might be a bit expensive on a database server. Having it
as a
On Thu, 2002-03-14 at 19:43, Bruce Momjian wrote:
Kyle wrote:
On the subject on client/server compression, does the server
decompress toast data before sending it to the client? Is so, why
(other than requiring modifications to the protocol)?
On the flip side, does/could the client
Are you trying to do a select for update?
Greg
On Fri, 2002-03-15 at 13:54, Lance Ellinghaus wrote:
I know it does not sound like something that would need to be done, but here
is why I am looking at doing this...
I am trying to replace a low level ISAM database with PostgreSQL. The low
On Fri, 2002-03-15 at 16:24, Neil Conway wrote:
On Fri, 2002-03-15 at 14:54, Lance Ellinghaus wrote:
I know it does not sound like something that would need to be done, but here
is why I am looking at doing this...
I am trying to replace a low level ISAM database with PostgreSQL. The
On Fri, 2002-03-15 at 19:44, Kyle wrote:
[snip]
Wouldn't Tom's suggestion of riding on top of ssh would give similar
results? Anyway, it'd probably be a good proof of concept of whether
or not it's worth the effort. And that brings up the question: how
would you measure the benefit? I'd
On Fri, 2002-03-15 at 21:45, Lance Ellinghaus wrote:
The application actually does not want nor need a consistent view of the
data. It is expecting that records that are locked will not be viewed at
all. The locks are normally held for VERY short periods of time. The fact
that the application
I previously replied to you vaguely describing a way you could implement
this by using a combination of client side caching and database tables
and triggers to allow you to determine if your cache is still valid.
Someone came right behind me, Tom maybe??, and indicated that the
proper/ideal way
On Sat, 2002-03-16 at 08:01, mlw wrote:
[snip]
If it is mostly static data, why not just make it a static page?
Because a static page is a maintenance nightmare. One uses a database in a web
site to allow content to be changed and upgraded dynamically and with a minimum
of work.
Oh ya, I
101 - 200 of 213 matches
Mail list logo
