-Original Message-
From: Francisco Jr. [mailto:[EMAIL PROTECTED]]
Sent: 22 April 2002 22:35
To: [EMAIL PROTECTED]
Subject: Re: Implement a .NET Data
Thanks Jean.
I will send a message to the ODBC list.
At least I didn't create the project in sourceforge
yet. I
On Tue, Apr 23, 2002 at 09:15:22AM +0200, Hannu Krosing wrote:
On Tue, 2002-04-23 at 01:29, Martijn van Oosterhout wrote:
The dumping is more of an extra, the original idea was to check for errors
in the datafiles. Hence the working name of pgfsck. At the moment the
dumping dumps only
On Tue, 23 Apr 2002 [EMAIL PROTECTED] wrote:
Suggestion: Why not embed this information into the binary, and
provide some way of extracting it.
I like this!
[Downside: Announcement, script kiddies: If you find option
UPDATE_DESCR_TABS=1 in the configuration information, then there's a
On Tue, 23 Apr 2002, Martijn van Oosterhout wrote:
But I think the most useful behaviour should be to dump system fields
too, so mildly knowledgeable sysadmin can import the dump and do the
right thing afterwards (like restore data as it was before transaction
nr 7000)
Well, i didn't
Steffen Nielsen [EMAIL PROTECTED] writes:
I have tried using chunks technique when creating huge string for a stored
procedure (C code). I work like charm for small string, but when i create
large strings i get a server closed the connection unexpectedly :-(
Look for bugs in your code ;-).
Thomas Lockhart [EMAIL PROTECTED] writes:
I was thinking about something like make report which would mail the
results of ./configure to, say, the ports mailing list. We could mention
it in the text message printed at the end of the make cycle.
I think it'd be a bad idea to encourage people
OK, would people please vote on how to handle SET in an aborted
transaction? This vote will allow us to resolve the issue and move
forward if needed.
In the case of:
SET x=1;
BEGIN;
SET x=2;
query_that_aborts_transaction;
SET x=3;
COMMIT;
at the
Lincoln Yeoh wrote:
At 10:48 AM 4/18/02 -0400, mlw wrote:
Bruce Momjian wrote:
Have you tried reducing 'random_page_cost' in postgresql.conf. That
should solve most of your problems if you would like more index scans.
My random page cost is 1 :-)
What happens when you set random
Luis Alberto Amigo Navarro wrote:
Hi All.
I've been reading all the thread and I want to add a few points:
You can set enable_seqscan=off in small or easy queries, but in large
queries index can speed parts of the query and slow other, so I think it is
neccesary if you want Postgres to
* Bruce Momjian ([EMAIL PROTECTED]) [020423 12:30]:
1 - All SETs are rolled back in aborted transaction
2 - SETs are ignored after transaction abort
3 - All SETs are honored in aborted transaction
? - Have SETs vary in behavior depending on variable
Our
Bradley McLean wrote:
* Bruce Momjian ([EMAIL PROTECTED]) [020423 12:30]:
1 - All SETs are rolled back in aborted transaction
2 - SETs are ignored after transaction abort
3 - All SETs are honored in aborted transaction
? - Have SETs vary in behavior depending on
Hi!
I checked out the StringInfo functions, they are basicly the same as the
Chunks functions I use, but I'll use the others instead even thought I don't
think they will help me on my problem. But anyway, I've checked out the malloc
and realloc function, and believe that they won't allow
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
http://archives.postgresql.org/pgsql-general/2001-09/msg00234.php
Nobody opposed to the idea of name ordering in that thread.
Okay, I've committed the fixes that implement this.
But note that this is on TODO:
* Allow user to
Tatsuo Ishii wrote:
Tatsuo Ishii [EMAIL PROTECTED] writes:
In my understanding we are going to turn on the --enable-syslog
*configure* option by default (or remove the configuration option
completely), but not change the syslog option in postgresql.conf
(currently default to 0: that
1
SET should follow transaction semantics and rollback.
Jan
Bruce Momjian wrote:
OK, would people please vote on how to handle SET in an aborted
transaction? This vote will allow us to resolve the issue and move
forward if needed.
In the case of:
SET x=1;
Bruce Momjian [EMAIL PROTECTED] writes:
1 - All SETs are rolled back in aborted transaction
2 - SETs are ignored after transaction abort
3 - All SETs are honored in aborted transaction
? - Have SETs vary in behavior depending on variable
My vote is 1 - roll back all
Andreas Scherbaum wrote:
Tom Lane wrote:
Andreas Scherbaum [EMAIL PROTECTED] writes:
On the other hand, i copied some parts from contrib/noupdate (there'e no
licence in the readme) and now i think, this is contributed under BSD
licence.
I'm sure or i'm wrong? I think, i have to
Each test set has 3 time sets.
First is on pgbench -i (-s 5)
Second is on pgbench -t 3000 -s 5
Third is on postmaster during the run of the first 2.
The first test on a slow harddrive has a large effect for increasing the
namedatalen length.
Second through 4th sets don't really show any
Discription of patch for python.
---
Andrew Johnson wrote:
On Wed, Apr 17, 2002 at 10:12:10PM -0400, Bruce Momjian wrote:
No one has replied, so I worked up a patch that I will apply in a few
days. Let me know if
I also want to implement the same feature but for
ecpg. On INFORMIX there is the following syntax to control
timeouts:
SET LOCK MODE TO [WAIT [seconds] | NO
WAIT]
There is 2 possibilities:
- either the pre-processor implements execution of
the statement with the asynchronous functions.
Michael Meskes wrote:
As some may know I will be talking about PostgreSQL on LinuxTag (6th of
June - 9th of June) in Karlsruhe, Germany. In particular I want to
address:
- The functionality of PostgreSQL
- Its stability and capability of handling large databases, ideally by
some case
On Tuesday 23 April 2002 04:27 pm, Bruce Momjian wrote:
OK, would people please vote on how to handle SET in an aborted
transaction? This vote will allow us to resolve the issue and move
forward if needed.
at the end, should 'x' equal:
1 - All SETs are rolled back in aborted
Bruce Momjian wrote:
OK, would people please vote on how to handle SET in an aborted
transaction? This vote will allow us to resolve the issue and move
forward if needed.
In the case of:
SET x=1;
BEGIN;
SET x=2;
query_that_aborts_transaction;
SET x=3;
Tom Lane wrote:
Michael Loftis [EMAIL PROTECTED] writes:
IE I'd like to have the information come back as say a notice or maybe
as extra information for an EXPLAIN for my purposes, but unless there is
interest, consensus on how it should be done, and a TODO item made of
it, I won't be
On Tue, 2002-04-23 at 12:52, Martijn van Oosterhout wrote:
Well, from my thinking about how you would use these fields in a logical
way, it seems it's possible for xmax to be non-zero if the transaction
numbered xmax was not committed. But in that case (unless it was a delete)
there would be
Nicolas Bazin wrote:
I read a thread about table lock timeout but don't know whether
anything has been done about it.
Here is what I'd like to do: I don't want my transactions to
be on hold for too long so I'd like to use a syntax I use on
INFORMIX already: SET LOCK MODE TO [WAIT
Thomas Lockhart writes:
I'd like to implement *something* to help us collect information on what
platforms actually have what features. This would be useful, for
example, for figuring out whether any platforms are lacking 8 byte
integers or are missing timezone infrastructure.
I don't think
Based on this report, I am adding a FUNC_MAX_ARGS define to
src/include/pg_config.h.win32. Certainly if we have INDEX_MAX_KEYS in
there, we should have FUNC_MAX_ARGS too.
---
Chris Ryan wrote:
Bruce,
I'm not
Michael Loftis wrote:
The benchmarks will depend mostly on the depth of the Btree. Hashes
will be markedly faster only in the case(s) where descending into the
tree to produce a matching leaf node would take longer than walking to
the appropriate item in a hash.
Most of the time until
Peter Eisentraut wrote:
Bruce Momjian writes:
Based on this report, I am adding a FUNC_MAX_ARGS define to
src/include/pg_config.h.win32. Certainly if we have INDEX_MAX_KEYS in
there, we should have FUNC_MAX_ARGS too.
We probably shouldn't have either one in there.
I thought so too,
Bruce Momjian writes:
Peter Eisentraut wrote:
Bruce Momjian writes:
Based on this report, I am adding a FUNC_MAX_ARGS define to
src/include/pg_config.h.win32. Certainly if we have INDEX_MAX_KEYS in
there, we should have FUNC_MAX_ARGS too.
We probably shouldn't have either one
Patch applied. Thanks.
---
Ulrich Neumann wrote:
Hello everybody,
If possible please add the following patch to better support NetWare.
best regards
Ulrich Neumann
Novell Worldwide Developer Support
begin
Updated version applied. Thanks.
---
Nicolas Bazin wrote:
Sorry for the package, but the following patch need to be applied to get the new
verion compiled on SCO Openserver 5.0.5 and Unixware 7.1.1
[ Attachment,
Patch applied. Thanks.
---
Mario Weilguni wrote:
Am Donnerstag, 11. April 2002 17:44 schrieb Tom Lane:
Mario Weilguni [EMAIL PROTECTED] writes:
And I did not find out how I can detect the large object
chunksize,
On 23 Apr 2002 23:36:14 -0300
Rod Taylor [EMAIL PROTECTED] wrote:
First is on pgbench -i (-s 5)
Second is on pgbench -t 3000 -s 5
Haven't several people observed that the results from pgbench are
very inconsistent? Perhaps some results from OSDB would be worthwhile...
The first test on a
Lincoln Yeoh wrote:
At 10:48 AM 4/18/02 -0400, mlw wrote:
Bruce Momjian wrote:
Have you tried reducing 'random_page_cost' in postgresql.conf. That
should solve most of your problems if you would like more index scans.
My random page cost is 1 :-)
What happens when you set
Curt Sampson wrote:
On Thu, 18 Apr 2002, Michael Loftis wrote:
mlw wrote:
The supposed advantage of a sequential read over an random read, in
an active multitasking system, is a myth. If you are executing one
query and the system is doing only that query, you may be right.
Haven't several people observed that the results from pgbench are
very inconsistent? Perhaps some results from OSDB would be
worthwhile...
I've not looked very hard at OSDB. But it doesn't seem to run out of
the box.
Based on that data, I'd vote against making any changes to
NAMEDATALEN.
On Tue, 23 Apr 2002, mlw wrote:
On a system that has neither read-ahead nor sorting of I/O requests,
yes. Which systems are you using that provide neither of these
facilities?
This only happens if the OS can organize the I/O requests in such a manner. It
is a non-trivial function.
This patch does not compile correctly:
pg_backup_archiver.c: In function `ahwrite':
pg_backup_archiver.c:1252: warning: pointer of type `void *' used in arithmetic
pg_backup_archiver.c:1259: warning: pointer of type `void *' used in arithmetic
pg_backup_archiver.c:1263: warning: pointer of type
Neil Conway [EMAIL PROTECTED] writes:
...Based on that data, I'd vote against making any changes to NAMEDATALEN.
It looked to me like the cost for going to NAMEDATALEN = 64 would be
reasonable. Based on these numbers I'd have a problem with 128 or more.
But as you observe, pgbench numbers are
41 matches
Mail list logo
