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
--
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
--
> 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
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
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 woul
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
"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 o
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 pg
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 Tu
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 , t
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 physical
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 cons
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 tim
=?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 syst
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:
test=
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 d
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, buffer2P
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);
pr
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
19 matches
Mail list logo
