But the description says: vacuum can run parallel to selects.
This is than not true.
Regards,
Michael
Tom Lane schrieb:
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
Description:after update: vacuum blocks parallel to select
This isn't a bug, it's simply vacuum waiting until it can ac
Tom Lane wrote:
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
If I call "psql -h localhost" it is very slow
compared to "psql -h 127.0.0.1" since for "localhost"
the nameservice is consulted.
This is not a bug; it's supposed to do that. If you don't like it,
reconfigure your name service (
Tatsuo Ishii wrote:
>
> > I have looked into my Linux box and found this in /usr/share/i18n/charmaps/BIG5.gz:
> > % Chinese charmap for BIG5 (CP950)
> > % version: 0.92
> > % Contact: Tung-Han Hsieh <[EMAIL PROTECTED]>
> > % Yuan-Chung Cheng <[EMAIL PROTECTED]>
> > % Distribution and us
Tatsuo Ishii wrote:
>
> > > > I reported bug #943 (I found in 7.3.2) and you checked in some change against
> > > > integer overflow.
> > > > Now I upgraded to 7.3.3 and I'm not happy with this.
> > > > The exact error as I described is fixed, but I found new errors in conversion
> > > > UTF-8 <
Tatsuo Ishii wrote:
>
> > Hello,
> > I reported bug #943 (I found in 7.3.2) and you checked in some change against
> > integer overflow.
> > Now I upgraded to 7.3.3 and I'm not happy with this.
> > The exact error as I described is fixed, but I found new errors in conversion
> > UTF-8 <-> EUC_TW
Hello,
I reported bug #943 (I found in 7.3.2) and you checked in some change against integer
overflow.
Now I upgraded to 7.3.3 and I'm not happy with this.
The exact error as I described is fixed, but I found new errors in conversion UTF-8
<-> EUC_TW and BIG5:
Copy to table (DB has UTF-8 encodin
Tatsuo Ishii wrote:
>
> > > > > There are "full width alphabets" in Japanese. Thoes include not only
> > > > > ASCII letters but also some European characters.
> > > >
> > > > Are these ASCII and European characters uppercased in some
> > > > Japanese-specific way ?
> > >
> > > Probably not, but
Tatsuo Ishii wrote:
>
> > > Are you sure that say, de_DE.utf8 locale produce meaningful results
> > > for any other languages?
> >
> > there are often subtle differences, but upper() and lower() are much
> > more likely to produce right results than collation order or date/money
> > formats.
> >
Tatsuo Ishii wrote:
>
> [Cc:ed to hackers]
>
> (trying select convert(lower(convert('X', 'LATIN1')),'LATIN1','UNICODE');)
>
> > Ok, this is working now (I cann't reproduce why not at the first time).
>
> Good.
>
> > Is it planned to implement it so that I can write lower()/ upper() for multib
Tatsuo Ishii wrote:
> I don't think using de_DE.utf8 helps. The locale support just calls
> tolower(), which is not be able to handle multibyte chars.
>
> > > Oops. That should be:
> > >
> > > select convert(lower(convert('X', 'LATIN1')),'LATIN1','UNICODE');
> > > It looks ugly, but works.
> >
>
10 matches
Mail list logo
