Tom Lane wrote:
Iavor Raytchev [EMAIL PROTECTED] writes:
Before the crash is this one -
FATAL 1: Sorry, too many clients already
That should be harmless --- I doubt it's relevant to the crash, unless
you have timestamps that prove it happened just before the crash.
True, after the
should
sprintf(buffer, %c, 0x5C);
readsz = 1;
buffer2Ptr =(unsigned char *) PQescapeBytea(buffer, readsz, esclen);
for (ctr = 0; ctr strlen(buffer2Ptr); ctr++)
{
printf(char[%d] is [%c]\n, ctr, buffer2Ptr[ctr]);
}
printf(esclen is [%d]\n, esclen);
Reid Thompson [EMAIL PROTECTED] writes:
should
sprintf(buffer, %c, 0x5C);
readsz = 1;
buffer2Ptr =(unsigned char *) PQescapeBytea(buffer, readsz, esclen);
for (ctr = 0; ctr strlen(buffer2Ptr); ctr++)
{
printf(char[%d] is [%c]\n, ctr, buffer2Ptr[ctr]);
On Sun, 10 Nov 2002, Tom Lane wrote:
In the last episode of this long-running issue, we decided that life
would be better if we make small-enough integer constants be initially
typed as int2 rather than int4, and then auto-promote them up to int4
when necessary.
What kind of type system do
Reid Thompson wrote:
should
[...snip...]
result in the following output?
char[0] is [\]
char[1] is [\]
char[2] is [\]
char[3] is [\]
esclen is [5]
buffer2Ptr is []
OR should it result in
char[0] is [\]
char[1] is [\]
esclen is [3]
buffer2Ptr is [\\]
It should result in the former:
=?ISO-8859-1?Q?Dennis_Bj=F6rklund?= [EMAIL PROTECTED] writes:
It seems to me that one would like to have a polymorphic typesystem with
constraints to handle overloading, subtyping or whatever is needed in
SQL.
What we have now is indeed pretty ad-hoc, but a full-blown type
inference system
Dear Tom,
I have removed the NO_MKTIME_BEFORE_1970 symbol from irix5.h,
rebuilt 7.3b2, and reran the regression. The three time tests
(tinterval, horology, abstime) now match the Solaris expected files.
I checked the timezone files, and the system does not appear to
have savings
I have been experimenting with empirical tests of file system and device
level writes to determine the actual constraints in order to speed up the WAL
logging code.
Using a raw file partition and a time-based technique for determining the
optimal write position, I am able to get 8K writes
Tom Lane writes:
One way to fix this is to make cross-category coercions to text not be
implicit casts. (I've opined before that that's a bad idea, but not
gotten a lot of support for changing it. Now that we have a distinction
between implicit and assignment casts, perhaps we could
Hi all!
PostgreSQL 7.3 beta5
Debian GNU/Linux 2.2r5 ( x86 )
.
All regression tests passed, except geometry.
The differences don't seem to be big. I think the test can be
validated, but i'm not absolutely sure. So i've attached the diff.
.
On the other hand, in psql ,
On Tue, Nov 12, 2002 at 03:20:52AM +0200, [EMAIL PROTECTED] wrote:
validated, but i'm not absolutely sure. So i've attached the diff.
Oops , forgot to attach it in the first message.
This is the diff.
*** ./expected/geometry.out Thu Nov 29 20:57:31 2001
--- ./results/geometry.out
We have seen a few reports (eg from Hervé Piedvache) of VACUUM FULL
in 7.2 producing messages like
dbfr=# VACUUM FULL VERBOSE ANALYZE pg_class ;
NOTICE: --Relation pg_class--
NOTICE: Rel pg_class: Uninitialized page 9 - fixing
NOTICE: Rel pg_class: Uninitialized page 10 - fixing
NOTICE: Rel
Curtis Faith [EMAIL PROTECTED] writes:
Using a raw file partition and a time-based technique for determining the
optimal write position, I am able to get 8K writes physically written to disk
synchronously in the range of 500 to 650 writes per second using FreeBSD raw
device partitions on IDE
Vadim,
In LockBuffer() you wrote
else if (mode == BUFFER_LOCK_EXCLUSIVE)
{
LWLockAcquire(buf-cntx_lock, LW_EXCLUSIVE);
/*
* This is not the best place to set cntxDirty flag (eg indices do
* not always change buffer they lock in excl mode). But please
Tom,
When you restructured the unique index location and validation for
foreign key constraints around 9/22 you added the restriction that the
supporting unique index may not be functional. I believe that this
restriction is not necessary. Suppose I had a unique index on
LOWER(login). That
Kris Jurka [EMAIL PROTECTED] writes:
When you restructured the unique index location and validation for
foreign key constraints around 9/22 you added the restriction that the
supporting unique index may not be functional. I believe that this
restriction is not necessary.
Hmm ... I'm not
hello,
recently i downloaded postgresql-7.3b5,i found the conversion between
gb18030 and utf was mistake because the map file bwteen them wasn't
obviously right.the first byte of utf8 encoding with two bytes shoule
between 0xc0 with 0xfd,the map file didn't accord with this condition
Are we ready for RC1 yet?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Bruce Momjian [EMAIL PROTECTED] writes:
Are we ready for RC1 yet?
I think so. The NO_MKTIME_BEFORE_1970 issue was bothering me, but I
feel that's resolved now. (It'd be nice to hear a crosscheck from
some AIX users though...)
regards, tom lane
19 matches
Mail list logo
