d a login
> name and a public key.
I will send you later.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
the outermost.
Here is new patches fixing the bug you pointed out (patches was
created by Yoshiyuki). Also I added your SQL to the regression test,
and now the patches is against CVS HEAD. For your convenience I also
include patches against the previous version.
--
Tatsuo Ishii
SRA OSS, Inc.
es about
> not having outer JOINs, etc. in it, but otherwise make it opaque to
> the error-checking code?
>
> I know I didn't explain that well, but the above SQL should work and
> the error appears to stem from the parser's looking at the innermost
> UNION ALL instead
on the one posted before.
BTW, I'm traveling to the United States from Aug 4 to Aug 12. I'm
going to join Linux World, PGDay and pgpool party at Bruce's. I hope
to meet many community poeple soon!
--
Tatsuo Ishii
SRA OSS, Inc. Japan
recursive_query.patch.gz
Description: Binary
; array_upper(t2.path,1) > 2
> )
> GROUP BY t1.id;
> ERROR: unrecognized node type: 203
Thanks for the report. Here is the new patches from Yoshiyuki against
CVS HEAD. Also I have added your test case to the regression test.
> Please apply the attached patch to he
> )
> GROUP BY t1.id;
> ERROR: unrecognized node type: 203
Thanks for the report. We will look into this.
> Please apply the attached patch to help out with tab
> completion in psql.
Ok, it will appear in the next patches.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
--
Sent via pgsql-patc
> On Wed, Jul 23, 2008 at 10:59:20AM -0400, Tom Lane wrote:
> > Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > > Reviewers, please let me know if you find problems with the
> > > patches. If none, I would like to commit this weekend.
> >
> > Has thi
> On Wed, Jul 23, 2008 at 10:59:20AM -0400, Tom Lane wrote:
> > Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > > Reviewers, please let me know if you find problems with the
> > > patches. If none, I would like to commit this weekend.
> >
> > Has thi
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > Reviewers, please let me know if you find problems with the
> > patches. If none, I would like to commit this weekend.
>
> Has this patch actually been reviewed yet? The only reports I've
> seen are from testing; n
est WITH RECURSIVE patches against CVS HEAD.
Reviewers, please let me know if you find problems with the
patches. If none, I would like to commit this weekend.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
recursive_query.patch.gz
Description: Binary data
--
Sent via pgsql-patches mailing list (pgsql-patch
Hi,
Here is the lastest WITH RECURSIVE patches against 2007/07/17 CVS (CVS
HEAD won't compile for me).
This version includes regression tests and is almost ready for commit
IMO.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
recursive_query.patch.gz
Description: Binary data
--
Sent via pgsql-pa
> On Mon, Jul 21, 2008 at 08:19:35AM +0900, Tatsuo Ishii wrote:
> > > > Thus I think we should avoid this kind of ORDER BY. Probably we should
> > > > avoid LIMIT/OFFSET and FOR UPDATE as well.
> > >
> > > What of index-optimized SELECT max(...) ?
>
SELECT 1 UNION ALL SELECT max(n) FROM x)
SELECT * FROM x;
produces an error.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
> This crashes the backend:
>
> WITH RECURSIVE t(n) AS (
> VALUES (1)
> UNION ALL
> SELECT n+1 FROM t WHERE n < 5 ORDER BY 1
> )
> SELECT n FROM t;
>
> apparently because of the ORDER BY 1
Thanks for the report. I think ORDER BY in this case is useless
anyway. ORDER BY affects (VALUES
> > Here is the lastest WITH RECURSIVE patches against CVS HEAD created by
> > Yoshiyuki Asaba and minor corrections by Tatsuo Ishii.
>
> I tried this patch vs. CVS HEAD used my usual configure option with
> only --with-prefix set, then tried to make, and got:
>
> m
Hi,
Here is the lastest WITH RECURSIVE patches against CVS HEAD created by
Yoshiyuki Asaba and minor corrections by Tatsuo Ishii. (David Fetter's
psql help patches are not included. It seems his git repository has
gone).
This version implements:
- detect certain queries those are not
> On Wed, Jul 16, 2008 at 01:57:04PM +0900, Tatsuo Ishii wrote:
> > > > No idea. What do you think if we allow only one query name at the
> > > > moment.
> > >
> > > I'm not sure I understand what that has to do with sorting.
> > >
> On Wed, Jul 16, 2008 at 09:37:25AM +0900, Tatsuo Ishii wrote:
> > > On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote:
> > > > Here is the patches he made against CVS HEAD (as of today).
> > > >
> > > > According to him followings ar
> On Tue, Jul 08, 2008 at 06:01:05PM +0900, Tatsuo Ishii wrote:
> > Here is the patches he made against CVS HEAD (as of today).
> >
> > According to him followings are fixed with the patches:
> >
> > - fix crush with DISTINCT
> > - fix creating VIEW
>
result
- fix inifinit recursion with OUTER JOIN
Not yet fixed:
- detect certain queries those are not valid acroding to the standard
- sort query names acording to the dependency
- planner always estimate 0 cost for recursion plans
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> > - SQL:2008 に規定されている
> On Sun, May 18, 2008 at 08:51:29PM +0900, Tatsuo Ishii wrote:
> > WITH RECURSIVE patch V0.1
> >
> > Here are patches to implement WITH RECURSIVE clause. There are some
> > limitiations and TODO items(see the "Current limitations" section
> > below
sions with Tatsuo Ishii ([EMAIL PROTECTED]).
- prior patches:
http://archives.postgresql.org/pgsql-patches/2008-03/msg00327.php
The patches include some extentions to the patches above.
2. Design proposales
See: http://archives.postgresql.org/pgsql-hackers/2008-02/msg00642.php
3. Implementati
Patches applied. Thanks.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
>
> > The cause of this is obvious and easy to fix. However I wonder this is
> > because of accidental old or wrong patches. Can you resubmit new patches
> > aga
var'
(note that the line number might be different what it should be in
your work file since I have applied Yoshiyuki's patches in prior).
The cause of this is obvious and easy to fix. However I wonder this is
because of accidental old or wrong patches. Can you resubmit new patches
Patch applied. Thanks.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> Hi,
>
> I ran pgbench with -C option. Here is an output.
>
> % pgbench -C -c 10 -t 100 bench
> starting vacuum...end.
> transaction type: TPC-B (sort of)
> scaling factor: 1
> number of clients: 10
&
Here is the proposed patches. If there's no objection, I will
commit(or Shall I wait for next "commit festa"?).
Note that I decide to use lo_import_with_oid, but the signature is
changed(the second and the third arguments are swapped because it
seems more natural).
--
Tatsuo Ish
Can someone enligten me what the usecase for CREATE TABLE LIKE at this
moment is?
I read the doc and followed the discssion in this thread in
pgsql-patches list but it was hard for me to figure out.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> I've applied the latest version of the patch
Patch committed. Thanks.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> On 4/6/07, Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
> >
> >
> > BTW, is anybody working on enabling the fill factor to the tables used
> > by pgbench? 8.3 will introduce HOT, and I think adding the f
Patch committed. Thanks.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> The attached is a patch to optimize contrib/pgbench using new 8.3 features.
>
> - Use DROP IF EXISTS to suppress errors for initial loadings.
> - Use a combination of TRUNCATE and COPY to reduce WAL on creating
> the
re
will make it easier to test HOT.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> > ---
> >
> > ITAGAKI Takahiro wrote:
> > > The attached is a patch to optimize contrib/pgbench using new 8.3
> > >
by the
author, but the patches still include the feature. So I'm confused.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> > ---
> >
> > Greg Smith wrote:
> > > This patch changes the way pgbe
> Tatsuo, would you please comment on this patch too?
No problem. I will come up with a comment by the end of this week.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> ---
>
> Greg Smith wrote:
> > This patch chang
> Tatsuo, would you please comment on this patch?
Sure. I will come up with a comment by the end of this week.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> ---
>
> ITAGAKI Takahiro wrote:
> > The attached is a
nt of HOT posted by
Simon on 2007/02/07. I wonder what have changed since the proposal.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Can we distinguish mingw case from others so that we could ifdef out
the extra fflush()?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> pgbench reports its progress of loading ("N tuples done.") or vacuuming
> ("vacuum...end"), but the messages are not printed on the moment on mi
Can we distinguish mingw case from others so that we could ifdef out
the extra fflush()?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> pgbench reports its progress of loading ("N tuples done.") or vacuuming
> ("vacuum...end"), but the messages are not printed on the moment on mi
Thanks. I have committed your patches.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> Hi Tatsuo-san and folks,
>
> This is a fix in pgbench to handle empty lines in external scripts.
> The manual says
> | Empty lines and lines begging with "--" will be ignored.
> but AFAICS,
Also we will continue to support legacy version until
pgpool-II becomes stable enough.
Also you might want to add pgpool development site URL.
FYI, pgpool-II presentation material for PostgreSQL Anniversary Summit
can be obtained from:
http://www.sraoss.co.jp/event_sem
Good catch!
Thanks. I have committed your fix.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> I found a buffer overflow bug in contrib/pgbench.
> This occures when -c >= 2.
>
>
>
> The type of 'state' is CState*, so we should use state+1 or &state[1],
> not state
week.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Index: pgbench.c
===
RCS file: /cvsroot/pgsql/contrib/pgbench/pgbench.c,v
retrieving revision 1.50
diff -c -r1.50 pgbench.c
*** pgbench.c 26 Jul 2006 07:24:50 - 1.50
--- pgbench.c 27 Jul
> > 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:
>
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
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
> >
> &
> On 23/12/2005 03:59, Tatsuo Ishii wrote:
> > BTW, the example code sequence (ISO-8859-8) Sagi posted seems to have
> > wrong one.
> >
> > select '$,3u=u=u=u=u=u=u=u=(B';
> > WARNING: ignoring unconvertible ISO_8859_8 character 0x00d7
> > :
&g
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > I think the current implementaion in utf8_and_iso8859.c is fast but
> > too fragile against rearranging of encoding id. I modify those functions
> > in utf8_and_iso8859.c to do a linear search with encoding id.
>
> T
eed to add the conversion for the code?
What do you think, Sega?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> That is a nice solution --- instead of listing all the encodings, you
> listed just the ones that need to be used. The list is shorter and
> clearer. It seems like the righ
> Tom Lane wrote:
> > Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > >> It looks like somebody rearranged the pg_enc enum without bothering to
> > >> fix the tables that are affected by this.
> >
> > > I will look into this.
> >
>
I have commited your fixes into PostgreSQL 8.1 stable branches.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> Hi Tatsuo,
>
> Attached is a proposed patch that deals with a couple of pgbench issues.
>
> The change at line 490 updates doCustom's local variable "commands"
p?plugin=attach&pcmd=open&file=ppgbench-20050906-3.tar.bz2&refer=PostgreSQL%2Fppgbench
You might want to try.
> Anyway, since I'm not sure of either of these changes, I'm passing them
> to you for review.
Your patches seem fine.
--
Tatsuo Ishii
SRA OSS, Inc. J
> Having blank lines in -f scripts was causing silent failures. This
> fixes it, for some value of "fixes." If it's OK, please apply to 8.1
> CURRENT and CVS TIP :)
Thanks. I have committed your patches to current and 8.1 stable.
--
Tatsuo I
e charsets/collataions, I think we need to change
the way to represent character strings from the unstructured "char *"
to more intelligent structure (I know it's hard to implement that
without significant performance loss, but I know we should do it in
the future).
So "unsig
objection to applying this patch now (ie, before beta3)?
> It's not quite a bug fix, but I think it'll make it easier to find
> bugs going forward.
For me, your patche seems to be a retrogression. In my understanding,
the reason why PostgreSQL uses "char *" in many places is
0m0.070s
3) no encoding conversions
$ time psql -c 'set client_encoding to 'EUC_JP';select * from accounts;' test
>/dev/null
real0m3.220s
user0m1.760s
sys 0m0.070s
I got the 52% overhead decreases to 18% with the patches. This is a
huge improvement! I wi
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> >> In mic_to_euc_jp(), the call of mic2sjis() is a mistake.
> >> It is necessary to call mic2euc_jp() here.
>
> > Thanks. The bug was there since 7.3. Apparently nobody uses
> > MIC->EUC_JP conversion
nversion (This is not surprising since very few people
use Mule Internal Code). So I commit the fix to current only. Please
let me know if back patch is neccessary.
--
Tatsuo Ishii
---(end of broadcast)---
TIP 3: if posting/reading through U
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;
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 m
uldn't be a problem. However if other APIs
put in such a data, you will get into trouble...
--
Tatsuo Ishii
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
nly allows
24-bit range, why we need to allow usage against the specification?
--
Tatsuo Ishii
---(end of broadcast)---
TIP 8: explain analyze is your friend
there's
actually a need for 32-but width character sets. Even Unicode only
uese up 0x0010, so 24-bit should be enough...
--
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])
ing since I
> could assign different table spaces for table and indexes.
> It would be even better to assign different tablespaces for each
> index.
Hm. It seems there's a problem with tablespaces. What I did was:
pgbench -i test
alter table accounts set tablespace
able and indexes.
It would be even better to assign different tablespaces for each
index.
--
Tatsuo Ishii
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
e job
above. Quick test with EUC-JP indicates that it is working, but still
need testing for many other encodings. Also, currently for UTF-8 and
MULE_INTERNAL it returns always 1, which is not correct of course. I
will look into this within a week..(i have a dealine for a magazine
article and h
> Tatsuo Ishii wrote:
> > It's surprising that nobody noticed the bug until now. It seems it has
> > been there since 7.3 days. I would like to make a back patch for
> > 7.3-stable if nobody objects.
>
> It's my bug :( -- sorry about that. Here's a 7.3 pa
reSQL Users' Group. Please let me know if
both users group could make some collaboration, such as having a
seminar in Korea or in Japan.
--
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])
65 matches
Mail list logo
