it simple until we have tried it out.
Right. AFAIK nobody has proposed charsets/collations onto disk.
--
Tatsuo Ishii
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
you only need to store one piece of
information anyway.
In my understanding the relation between charset and collation is
1:N. Thus storing only a collation is sufficient to determine the
charset. However a charset cannot determine a collation.
--
Tatsuo Ishii
---(end
.), this is really a nonissue.
I agree with Peter.
--
Tatsuo Ishii
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Hi Tatsuo,
I've made a new release:
http://prdownloads.sourceforge.net/osdldbt/dbt3-v1.5.tar.gz?download
Let me know if there are any problems.
Thanks!
Just for quick note, it seems query 19 takes forever. Have you
successfully run Q19?
--
Tatsuo Ishii
info. The query was not finished within 3
days and was canceled on a Dual Xeon 2.8GHz with 2.5GB RAM running
Linux. PostgreSQL is 7.4.5 with default postgresql.conf. An explain
output is attatched.
--
Tatsuo Ishii
Tatsuo Ishii [EMAIL PROTECTED] writes:
Just for quick note, it seems query 19 takes forever. Have you
successfully run Q19?
Here is the more detailed info. The query was not finished within 3
days and was canceled on a Dual Xeon 2.8GHz with 2.5GB RAM running
Linux. PostgreSQL is 7.4.5
the number of combinations
is too large or not known.
Also, we mention you should use the C locale to use normal indexes for
LIKE but isn't it more correct to say the encoding has to be SQL_ASCII?
Why? C locale works well for multibyte encodings such as EUC-JP too.
--
Tatsuo Ishii
and bytea, respectively.
How do you solve the problem, text and bytea require large amount of
RAM?
--
Tatsuo Ishii
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
the 52% overhead decreases to 18% with the patches. This is a
huge improvement! I will commit to current if there's no objection.
--
Tatsuo Ishii
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send
.
My opinion is, we'd better test with at least 8.0, or even better with
current. I think I can do the testing after Jul 1 if those features
are remained. I have a dual Xeon system with a 15000RPM SCSI disk
system in my office.
--
Tatsuo Ishii
---(end of broadcast
.
--
Tatsuo Ishii
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
It seems current CE implementation ignores UPDATE, DELETE quries. Is
this an intended limitation?
--
Tatsuo Ishii
So far, the CE patch covers only inherited child tables and is only
effective when enable_constraint_exclusion is true.
There have been various requests for this to work
() becomes public funtion?
--
Tatsuo Ishii
/*
* $PostgreSQL$
*
* Copyright (c) 2005 Tatsuo Ishii
*
* Permission to use, copy, modify, and distribute this software and
* its documentation for any purpose, without fee, and without a
* written agreement is hereby granted, provided that the above
Tatsuo Ishii [EMAIL PROTECTED] writes:
With a help from Bruce, I wrote a small function which returns row
locking information(see attached file if you are interested).
Scanning the whole table seems a bit slow :-(
Yes, but I couldn't find any other way.
There is another possibility
Tatsuo Ishii [EMAIL PROTECTED] writes:
If I understand correctly, it seems the above method does show a
locked row's TID which does not block someone else. That is a little
bit different from what I expcted.
Well, it *could* be blocking someone else. If there were more than one
waiter
+---++---+---
(0,1) | Shared| 3 | t | {646,647}
(1 row)
Am I missing something?
--
Tatsuo Ishii
/*
* $PostgreSQL$
*
* Copyright (c) 2005 Tatsuo Ishii
*
* Permission to use, copy, modify, and distribute this software and
* its
On Fri, Aug 12, 2005 at 12:27:25PM +0900, Tatsuo Ishii wrote:
However even one of transactions, for example 647 commits, still it
shows as if 647 is a member of muitixid 3.
test=# select * from pgrowlocks('t1');
locked_row | lock_type | locker | multi | xids
On Fri, Aug 12, 2005 at 02:08:29PM +0900, Tatsuo Ishii wrote:
On Fri, Aug 12, 2005 at 12:27:25PM +0900, Tatsuo Ishii wrote:
However even one of transactions, for example 647 commits, still it
shows as if 647 is a member of muitixid 3.
test=# select * from pgrowlocks('t1
into
storage/ipc/procarray.c. This is similar to BackendPidGetProc() except
that it accepts xid as an argument. Any objection?
--
Tatsuo Ishii
/*
* BackendXidGetProc -- get a backend's PGPROC given its XID
*
* Returns NULL if not found. Note that it is up to the caller to be
* sure that the question
Tatsuo Ishii [EMAIL PROTECTED] writes:
To accomplish this I need to add following function into
storage/ipc/procarray.c. This is similar to BackendPidGetProc() except
that it accepts xid as an argument. Any objection?
if (xid == 0) /* never match dummy
On Fri, Aug 19, 2005 at 09:19:24PM +0900, Tatsuo Ishii wrote:
Tatsuo Ishii [EMAIL PROTECTED] writes:
To accomplish this I need to add following function into
storage/ipc/procarray.c. This is similar to BackendPidGetProc() except
that it accepts xid as an argument. Any objection
.
Right. We Japanese (and probably Chinese too) have been bugged by the
broken mutibyte locales for long time. Using C locale help us to a
certain extent, but for Unicode we need correct locale data, othewise
the sorted data will be completely chaos.
--
SRA OSS, Inc. Japan
Tatsuo Ishii
Hi,
I have been looking around optimizer's code and found a comment:
/*
* process_duplicate_ors
*Given a list of exprs which are ORed together, try to apply
*the inverse OR distributive law.
Anybody enlighten what inverse OR distributive law is?
--
SRA OSS, Inc. Japan
Tatsuo
, your patche seems to be a retrogression. In my understanding,
the reason why PostgreSQL uses char * in many places is just it was
designed in the old days when ASCII was the only charset in the world.
--
SRA OSS, Inc. Japan
Tatsuo Ishii
---(end of broadcast
hard to implement that
without significant performance loss, but I know we should do it in
the future).
So unsigned char* is not enough for the goal anyway, I'm not against
your patches.
--
SRA OSS, Inc. Japan
Tatsuo Ishii
---(end of broadcast)---
TIP
GB18030 needs 4-byte UTF-8 mappings.
If yes, we surely need to update utf8_to_gb18030.map.
Anybody familiar with GB18030/UTF-8?
--
SRA OSS, Inc. Japan
Tatsuo Ishii
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your
is quite usefull and I would like to
include in 8.1. Or should I keep it for 8.2?
--
SRA OSS, Inc. Japan
Tatsuo Ishii
*** pgbench/pgbench.c 2004-11-09 15:09:31.0 +0900
--- pgbench-new/pgbench.c 2005-09-27 14:31:34.0 +0900
***
*** 41,46
--- 41,49
#include sys
Tatsuo Ishii [EMAIL PROTECTED] writes:
I think the enhanced pgbench is quite usefull and I would like to
include in 8.1. Or should I keep it for 8.2?
Well, we've traditionally been laxer about contrib than the core
software, so the fact that we're past feature freeze isn't sufficient
Tatsuo Ishii [EMAIL PROTECTED] writes:
2) it requires a location where those scripts reside. $prefix/etc
seems appropriate?
I was thinking of just embedding the default scripts as constants in
the program text. A little bit ugly but saves a lot of headache with
needing to find
Michael Fuhr [EMAIL PROTECTED] writes:
A recent pgbench commit causes build failures due to an undefined
reference to strndup(), at least on FreeBSD and UnixWare:
Oops.
Yeah, breaks on HPUX too. Patch applied.
Thanks.
--
SRA OSS, Inc. Japan
Tatsuo Ishii
---(end
'JST' is not,
and 2005-10-14 12:00 Japan is NOT allowed while SET TIME ZONE
'Japan' is OK. Note that there's no daylight-saving time in Japan (at
this point).
--
SRA OSS, Inc. Japan
Tatsuo Ishii
---(end of broadcast)---
TIP 4: Have you searched our
Tatsuo Ishii [EMAIL PROTECTED] writes:
Shall I add JST to our zic database?
No. We have to update that from the upstream database every release;
maintaining our own private mods is not acceptable. If you want JST
to be recognized as a zic timezone, go lobby the upstream maintainers
-
2005-10-14 14:00:00
(1 row)
--
SRA OSS, Inc. Japan
Tatsuo Ishii
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Hi, I can run following odd command(note that no spaces between 1 and
where):
test=# select 1where true;
?column?
--
1
(1 row)
Is this a bug or a feature? This is PostgreSQL 8.1.0.
--
SRA OSS, Inc. Japan
Tatsuo Ishii
---(end of broadcast
Has anybody tried Solaris8 or 9/ADM64(SUN Fire v40 for example) combo?
I personally don't have access to this platform, but am interested in
someone else has already tried.
--
Tatsuo Ishii
I have started filling in the supported platform list for the 8.0.0
release with the information from
of the fact that some
langauges do not work.
Same thing can be said to EUC-JP, EUC-CN and EUC-KR and so on as well.
I strongly object the policy to try to unconditionaly disable UTF-8
support on win32.
--
Tatsuo Ishii
From: Magnus Hagander [EMAIL PROTECTED]
Subject: RE: [pgsql-hackers-win32
to do
that in a reasonable way.
At this point I'd say that any combination of UTF8 encoding with a non
C/POSIX locale probably isn't going to work on Windows. Tatsuo, do you
know of other cases that will work?
No. I think C is the only working locale.
--
Tatsuo Ishii
stream. But it can be encoded in 7-bit too. So when we refer to
LATIN1(ISO-8859-1), it's not clear if it's encoded in 7/8-bit.
--
Tatsuo Ishii
From: Bruce Momjian pgman@candle.pha.pa.us
Subject: Re: [HACKERS] UTF8 or Unicode
Date: Mon, 21 Feb 2005 22:08:25 -0500 (EST)
Message-ID: [EMAIL PROTECTED]
Tom
unliable
network or hardware.
However it would be easy to modify pgpool to allow automatic switch
back (with a risk of unwanted repeating switching, of course). Is
this what you want?
--
Tatsuo Ishii
---(end of broadcast)---
TIP 5: Have you checked our
On Thu, 10 Mar 2005, Tatsuo Ishii wrote:
I'm experimenting with pgpool 2.51 on my Linux box runnung
two postgresql backends: pg74:5432 and pg801:5433
I configured pgpool to use pg74:5432 as primary backend and
pg801:5433 as second one. Pgpool is running on default port () and
I
running
system's performance steady, we need to avoid table/index bloat(I
assume incoming trasanction rate is constant). Surely vacuum delay
reduces the impact, but the cost is taking longer time to salvage free
spaces, and FMS will run out due to incoming transactions, no?
--
Tatsuo Ishii
DropRelFileNodeBuffers
was willing to arbitrarily throw away a pin on a victim buffer.
I thought that was a bad idea and took it out, expecting that we'd find
any bad consequences a bit quicker than this ...
It seems your patches do not fix the case when the table is a
temporary table...
--
Tatsuo
I noticed that explain analyze emits a little bit funny reslut for
bitmap scans:
BitmapOr (cost=157.36..157.36 rows=18894 width=0) (actual time=9.406..9.406
rows=0 loops=1)
Why actual rows=0?
--
Tatsuo Ishii
---(end of broadcast)---
TIP 8
.
Why? Since the functions need to be written in C language, ordinary
users cannot make them anyway. Same thing can be said to CREATE TYPE.
--
Tatsuo Ishii
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
boost disk
access performance.
--
Tatsuo Ishii
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
BTW is it possible to let BitmapHeapScan fetch tuples by TID order?
It already does ...
Oh great. It seems tbm_begin_iterate() does the trick...
--
Tatsuo Ishii
---(end of broadcast)---
TIP 7: don't forget to increase your free space map
Bruce Momjian wrote:
(B
(B There are two reasons for that optimization --- first, some
(B locale support is broken and Unicode encoding with a C locale
(B crashes (not an issue for ICU), and second, it is an
(B optimization for languages like Japanese that want to use
(B unicode,
frequently, especially for LATIN languages. Thus maintaining cost is
not too high.
--
Tatsuo Ishii
ICU also has a fair few conversions that we do not have at present.
That is a much larger issue, similar to our shipping our own timezone
database. What does it buy us?
o Do we ship
Are we going to put the fixes into 8.0.3 and so on? Or will it be
included in 8.0.4?
--
Tatsuo Ishii
I promised an analysis of the problems Jan Wieck uncovered yesterday,
so here it is.
Jan had developed a testbed (which I hope he will post) that essentially
has a bunch of client threads
a
place and the fix is included in the patches.
Madison,
If you are interested in the patches, I could send it to you.
Hackers,
Do you think the functionality something like above is worth to add to
PostgreSQL?
--
Tatsuo Ishii
Hi all,
I've been chasing down a bug and from what I have
Tatsuo Ishii wrote:
Sent: Sunday, May 08, 2005 12:01 PM
To: [EMAIL PROTECTED]
Cc: pgsql-general@postgresql.org; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [GENERAL] Invalid unicode in COPY problem
We have developed patches which relaxes the character
validation so
Alvaro Herrera wrote:
Sent: Sunday, May 08, 2005 2:49 PM
To: John Hansen
Cc: Tatsuo Ishii; pgman@candle.pha.pa.us;
[EMAIL PROTECTED]; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Patch for collation using ICU
On Sun, May 08, 2005 at 02:07:29PM +1000, John Hansen wrote
I see WRITE_NODE_FIELD(whereClause) twice in _outSelectStmt(). Maybe a
bug?
--
Tatsuo Ishii
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
information). Thus SJIS-EUC_JP-SJIS conversion using ICU does not
preserve original text.
--
Tatsuo Ishii
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED
On Sun, May 08, 2005 at 02:07:29PM +1000, John Hansen wrote:
Tatsuo Ishii wrote:
So Japanese(including ASCII)/UNICODE behavior is
perfectly correct
at this moment.
Right, so you _never_ use accented ascii characters in
Japanese?
(like è for example
-Original Message-
From: Tatsuo Ishii [mailto:[EMAIL PROTECTED]
Sent: Sunday, May 08, 2005 11:08 PM
To: John Hansen
Cc: pgman@candle.pha.pa.us; [EMAIL PROTECTED];
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Patch for collation using ICU
I don't buy
Tatsuo Ishii wrote:
Sent: Tuesday, May 10, 2005 12:32 AM
To: John Hansen
Cc: pgman@candle.pha.pa.us; [EMAIL PROTECTED];
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Patch for collation using ICU
-Original Message-
From: Tatsuo Ishii [mailto:[EMAIL PROTECTED
Hackers,
The problem he found is not only existing in Japanese characters but
also in any multibyte encodings including UTF-8. For me the patch
looks good and I will commit it to 7.3, 7.4, 8.0 stables and current
if there's no objection.
--
Tatsuo Ishii
Character type value including multibyte
I think you need to test with 5 characters, not 3.
--
Tatsuo Ishii
Ahemm,...
UNICODE DB:
create table t (a char(10));
set client_encoding = iso88591;
insert into t VALUES ('æøå');
select a, octet_length(a),length(a) from t;
a | octet_length | length
:
1) not need to worry about OID wrap around problem
2) easier to find orpahn LO
3) for replication systems it's easier to replicate LOs
What do you think?
--
Tatsuo Ishii
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ
the
description is quite correct from observing the actual implementation
(or the implementation is wrong).
A workaround I found so far was issuing Flush immediately after
Execute. I'm not sure if this is the correct solution, but I
couldn't find any better way.
Suggestions?
--
Tatsuo Ishii
SRA OSS
Tatsuo Ishii [EMAIL PROTECTED] writes:
However a extended query Execute does not return CommandComplete
(note: ErrorResponse will be returned if an error occurs). Although
the doc says Therefore, an Execute phase is always terminated by the
appearance of exactly one of these messages
and current.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through
received from an untrustworthy source. Otherwise
there is a security risk: you are vulnerable to SQL injection
attacks wherein unwanted SQL commands are fed to your database.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 3: Have you
Tatsuo Ishii [EMAIL PROTECTED] writes:
I suggest that PQescapeString() should have a parameter to specify the
encoding of to.
You mean the encoding of from, no?
Oops, from, yes.
But actually I'd argue that
letting the client programmer supply the encoding is still a pretty
dangerous
* Tatsuo Ishii:
Users can input value for var from a web form. The attacker inputs
following string:
(0x95+0x27);DELETE FROM members;--
where 0x95+0x27 is actually a SJIS mutibyte KANJI. Programmer applies
PQescapeString() to it and gets:
0x95+0x27+0x27;DELETE FROM members
and backend must have the same notion of SJIS).
No problem. We have the client encoding in PGConn. That's why Tom suggests
PQescapeString() should have the PGCConn argument.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 5: don't
Tatsuo Ishii [EMAIL PROTECTED] writes:
I suggest that PQescapeString() should have a parameter to specify the
encoding of to.
You mean the encoding of from, no?
Oops, from, yes.
But actually I'd argue that
letting the client programmer supply the encoding is still a pretty
On 2006-02-20, Tatsuo Ishii [EMAIL PROTECTED] wrote:
In further investigation, Akio Ishida found this kind of attack is
possible even with EUC_JP/UTF-8.
How?
The details have been sent to cores.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast
, size_t length)
If this is ok, I will implement for 8.2.
Here is the promised patches for 8.2. If there's no objection, I will
commit tomorrow.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
cvs diff: Diffing src/interfaces/libpq
Index: src/interfaces/libpq/fe-exec.c
. Could you tell me what the number column in the file is? Can I
assign arbitary number for the function? (maybe next to the last
number?) I'm not familiar with win32 build.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 2: Don't 'kill
On 2006-02-26, Tatsuo Ishii [EMAIL PROTECTED] wrote:
On 2006-02-20, Tatsuo Ishii [EMAIL PROTECTED] wrote:
In further investigation, Akio Ishida found this kind of attack is
possible even with EUC_JP/UTF-8.
How?
The details have been sent to cores.
I wasn't asking out of idle
.
At this point, I get no response from them so far.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Tatsuo Ishii [EMAIL PROTECTED] writes:
I guess I understand whay you are saying. However, I am not allowed to
talk to you about it unless cores allow me. Probably we need some
closed forum to discuss
-+-+---+-++
25 |2619 | 1663 | 16403 | 0 |
0
63 |2619 | 1663 | 16384 | 10 |
0
(2 rows)
Is it possible that a free space map entry has 0 blockfreebytes?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Peter Eisentraut wrote:
Am Dienstag, 7. März 2006 15:09 schrieb Tatsuo Ishii:
test=# select * from pg_freespacemap where blockfreebytes = 0;
blockid | relfilenode | reltablespace | reldatabase | relblocknumber |
blockfreebytes
() at postmaster.c:1277
#8 0x08168e71 in PostmasterMain (argc=3, argv=0x82eaf68) at postmaster.c:980
#9 0x08131f58 in main (argc=3, argv=0x82eaf68) at main.c:254
#10 0x40087c1f in __libc_start_main () from /lib/i686/libc.so.6
Any idea?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
not noticed this test case. Probably NULL is better
than zero.
Just for curiousity, why FSM gathers info for indexes? I thought FSM
is only good for tables.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 6: explain analyze is your
Mark,
I have tried your patches and it worked great. Thanks.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Tom Lane wrote:
Mark Kirkwood [EMAIL PROTECTED] writes:
Good points! I had not noticed this test case. Probably NULL is better
Would setting it to 'BLCKSZ - (fixed index header stuff
BTW, I noticed difference of outputs from pg_freespacemap and
pgstattuple.
I ran pgbench and inspected accounts table by using these tools.
pg_freespacemap:
sum of bytes: 250712
pgstattuple:
free_space: 354880
Shouldn't they be identical?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Tatsuo Ishii wrote:
BTW, I noticed difference of outputs from pg_freespacemap and
pgstattuple.
I ran pgbench and inspected accounts table by using these tools.
pg_freespacemap:
sum of bytes: 250712
pgstattuple:
free_space: 354880
Shouldn't they be identical
I have attached pgrowlocks tested under current.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Tatsuo, have you developed a new version of this for 8.2?
---
Tatsuo Ishii wrote:
Tatsuo Ishii [EMAIL PROTECTED] writes
then that's a bug.)
Then why do we have CREATE DEFAULT CONVERSION command at all?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Tatsuo Ishii [EMAIL PROTECTED] writes:
I don't mind having encoding conversions be named within schemas,
but I propose that any given encoding pair be allowed to have only
one default conversion, period, and that when we are looking for
a default conversion we find it by a non-namespace
Tatsuo Ishii [EMAIL PROTECTED] writes:
I'm sure we need more than one default conversion for encoding A and
B. For example, different vendors provide different conversion maps
for SJIS and UTF-8. M$ has its own and Apple has another one, etc. The
differences are not huge but some
such as LATIN* and SJIS.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Tatsuo, are you planning to add this to CVS HEAD?
Yes, I would like to add if there's no objection.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---
Tatsuo Ishii wrote:
I have attached pgrowlocks tested under current
Tatsuo Ishii wrote:
Tatsuo, are you planning to add this to CVS HEAD?
Yes, I would like to add if there's no objection.
I have heard no comment, and it looks useful, so please add it at your
convenience.
Ok, done.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
TABLE FKTABLE ( ftest1 int, ftest2 int, ftest3 int, ftest4 int,
CONSTRAINT constrname3 FOREIGN KEY(ftest1, ftest2, ftest3) REFERENCES PKTABLE);
NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY check(s)
CREATE
Any thoughts?
--
Tatsuo Ishii
select latin2 from t1;
P.S. I have used bsearch() to search code spaces. Is bsearch() is
portable enough?
--
Tatsuo Ishii
it before
heap_insert()
Comments?
--
Tatsuo Ishii
that are needed.
Simply clipping multibyte strings by atttypmode might produce
incorrect multibyte strings. Consider a case inserting 3 multibyte
letters (each consisting of 2 bytes) into a char(5) column.
Or this kind of consideration should be in bpcharin() as I said in the
earilier mail?
--
Tatsuo
, however, we could not fix the similar problem
for COPY FROM in the same way. Changing bpcharin() would solve
problems of both INSERT and COPY FROM. So bpcharin() seems more
appropreate place to fix both problems.
--
Tatsuo Ishii
It seems some incompatible changes have been made between 7.0 and
current. In 7.0, if a parameter is NULL OR a null string (""), then
the value from an environment variable is applied. However in current
ONLY NULL is considered. Is there any reason for this?
--
Tatsuo Ishii
Tatsuo Ishii [EMAIL PROTECTED] writes:
I'm going to fix the problem by changing bpcharin() rather than
changing exprTypmod(). Surely we could fix the problem by changing
exprTypmod() for INSERT, however, we could not fix the similar problem
for COPY FROM in the same way. Changing
In 7.0.2
select to_char(sum(n),'999') from t1;
causes backend dump a core if n is a float/numeric ...data type AND if
sum(n) returns NULL. This seems due to a bad null pointer handling for
aruguments of pass-by-reference data types. I think just a simple
null pointer checking at very top
ur non-gcc platform and please let me know if you have further
problem...
--
Tatsuo Ishii
-E unicode unicode
$ psql unicode
\encoding LATIN2
[some sessions follow using ISO8859-2]
:
:
Same note above...
--
Tatsuo Ishii
doesn't write
any datafiles on commit, only commit record goes to log
(and log fsync-ed). Dirty buffers remains in memory long
Is log fsynced even I turn of -F?
--
Tatsuo Ishii
Do you mind if we name this "--enable-unicode-conversion"? It's a bit
longer, but that's why they're called long options. :)
Sounds reasonable:-) Please go ahead and change it.
--
Tatsuo Ishii
not on each commit but each ~ 5sec, if
losing some recent commits is acceptable.
Sounds great.
--
Tatsuo Ishii
401 - 500 of 1607 matches
Mail list logo
