Re: [HACKERS] pg_trgm

> > It's not a practical solution for people working with prebuilt Postgres > > versions, which is most people. I don't object to finding a way to > > provide a "not-space" behavior instead of an "is-alnum" behavior, > > but as noted upthread a GUC isn't the right way. How do you feel > > about a

Re: [HACKERS] pg_trgm

e right way. How do you feel > about a new set of functions with an additional flag argument of > some sort? Let me see how many functions we need to create... -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgs

Re: [HACKERS] pg_trgm

> > select similarity(E'\u0441\u043B\u043E\u043D', E'\u0441\u043B\u043E > \u043D\u044B'); > similarity > > NaN > (1 row) Wait. This works fine for me with stock pg_trgm. local is C and encoding is UTF8. What version of PostgreSQL are y

Re: [HACKERS] pg_trgm

> Tatsuo Ishii writes: > > similarity -> generate_trgm -> find_word -> iswordchr -> t_isalpha -> > > isalpha > > > if locale is C and USE_WIDE_UPPER_LOWER defined which is the case in > > most modern OSs. > > Quite. And *if locale is C then

Re: [HACKERS] pg_trgm

t could stand > to be improved but it doesn't seem exactly critical. Really? similarity -> generate_trgm -> find_word -> iswordchr -> t_isalpha -> isalpha if locale is C and USE_WIDE_UPPER_LOWER defined which is the case in most modern OSs. -- Tatsuo Ishii SRA OSS,

Re: [HACKERS] Why my manualy constructed raw parser tree produce failed to execute?

ng equal(). Search #ifdef COPY_PARSE_PLAN_TREES in postgres.c to see how to use it. Good luck. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] pg_trgm

uses isascii() etc. to recognize a letter, which will skip any non ASCII range character in C locale. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make change

Re: [HACKERS] pg_trgm

\u043E\u043D', E'\u0441\u043B\u043E\u043D\u044B'); similarity 0.75 (1 row) Or you could just #undef KEEPONLYALNUM in trgm.h. But I'm not sure this is the right thing for you. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japane

Re: [HACKERS] pg_trgm

tion to use). Then > you can define an index using one or the other and the meaning would > be stable. It's worse. pg_trgm has another compile option "IGNORECASE" which might affect index opclasses. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_e

Re: [HACKERS] pg_trgm

y pg_trgm just same as Engligh. (Note that these preprocessing are done outside PostgreSQL world). The difference is just the "word" can be consists of non ASCII letters. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp --

Re: [HACKERS] pg_trgm

> Well, that doesn't mean that the answer is to use C locale ;-) Of course it's up to user whether to use C locale or not. I just want pg_trgm work with C locale as well. > However, you could possibly think about making this bit of code > more flexible: > > #ifdef KEEPONLYALNUM > #define iswordc

Re: [HACKERS] pg_trgm

ultibyte + C locale. Anyway locale is completely usesless for finding word vs non-character an agglutinative language such as Japanese. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (p

Re: [HACKERS] pg_trgm

ASCII letters and digits will be > recognized as word constituents. That means there is no chance to make pg_trgm work with multibyte + C locale? If so, I will leave pg_trgm as it is and provide private patches for those who need the functionality. -- Tatsuo Ishii SRA OSS, Inc. Japan Engl

Re: [HACKERS] pg_trgm

> > What is your locale? > It was en_EN.UTF-8. Interesting. With C it fails... Yes, pg_trgm seems to have problems with multibyte + C locale. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hacker

Re: [HACKERS] pg_trgm

6e53,0x1dc363,0x1e22e9} > (1 row) > > Time: 0.443 ms > test=# select similarity('日本語', '日本後'); > similarity > > 0.33 > (1 row) > > Time: 0.426 ms > > > Encoding is UTF-8... What is your locale? -- Tatsuo I

Re: [HACKERS] pg_trgm

w_trgm ------- {} (1 row) Encoding is EUC_JP, locale is C. Included is the script to reproduce the problem. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp pg_trgm.sql Description: Binary data -- Sent via pgsql-hackers mailing l

[HACKERS] pg_trgm

Hi, Anyone working on make contrib/pg_trgm mutibyte encoding aware? If not, I'm interested in the work. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or

Re: [HACKERS] exporting raw parser

s a waste of time and I would rather keep on borrowing the parse code. I thought there were several people who needed the API as well in the cluster meeting. If somebody who made such a vote in the meeting is on the list, please express your opinion for the API. I'm not in the position of spe

Re: [HACKERS] exporting raw parser

should not be a collection of half-baked functions. What do you mean by "should also be available in stand-alone"? If you want more abstract API than "libSQL", you could invent such a thing based on it as much as you like. IMO anything need to parse/operate the raw parse

Re: [HACKERS] exporting raw parser

r of ecpg, the maintenance problem with ecpg seems comes from that it needs to modify the grammer. My proposal does not require the grammer changes. So I don't understand why you think this would be difficult as ecpg. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/inde

[HACKERS] exporting raw parser

add performance degration nor maintenance cost. Comments? -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgres

Re: [HACKERS] How to know killed by pg_terminate_backend

m the shell. No problem (at least for pgpool-II). If the flag is not set, postgres returns the same code as the one killed by pg_terminate_backend(). The point is, backend is killed by postmaster or not. Because if backend was killed by postmaster, pgpool-II should not expect the PostgreSQL ser

Re: [HACKERS] How to know killed by pg_terminate_backend

ne ERRCODE_BACKEND_STOP_REQUEST MAKE_SQLSTATE('5','7', 'P','0','4') -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hacker

[HACKERS] How to know killed by pg_terminate_backend

n the otherhand, pg_terminate_backend() just terminates a backend. So triggering failover is overkill. Maybe we could make PostgreSQL a little bit smarter so that it returns a different code than 57P01 when killed by pg_terminate_backend(). Comments? -- Tatsuo Ishii SRA OSS, Inc. Japan English:

Re: [HACKERS] Reposnse from backend when wrong user/database request send

> Tatsuo Ishii writes: > >> Tatsuo Ishii writes: > >>> It seems between 8.4 and CVS HEAD backend responses 'E' packet > >>> (error/fatal message) if a startup packet sent with wrong user and/or > >>> database. Before backend responses

Re: [HACKERS] Reposnse from backend when wrong user/database request send

> Tatsuo Ishii writes: > > It seems between 8.4 and CVS HEAD backend responses 'E' packet > > (error/fatal message) if a startup packet sent with wrong user and/or > > database. Before backend responses 'R' packet first followd by 'E' > &

[HACKERS] Reposnse from backend when wrong user/database request send

nt this change because this is correct behavior. Just Pgpool has to live with previous behavior (it was wrong IMO) and recent change not to break existing pgpool applications. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent

Re: [HACKERS] Re: Hot Standby query cancellation and Streaming Replication integration

> not going to ship this year. Oh, 9.0 will not be shipped in 2010? You guys share same opinion as Tom? -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] function side effects

ot be confused with IMMUTABLE/STABLE. It seems it is neccessary to invent new marker for not only pgpool but HOT/SR (and may be Slony). They need to know if a query including functions do writes or not *before* sending to backend. Otherwise they got error because they sent a write q

Re: [HACKERS] function side effects

ting to log). Consider a function that calls those has-side-effect functions. We need a property which is inherited to child function to parent function. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] function side effects

ably it's enough for pgpool to have a "black list" of such that function. Maintaining such a list is a boring task but I cannot think of any good way at this point. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sen

Re: [HACKERS] function side effects

. However in most database application systems, it is possible that all functions are properly designed and implemented (at least they want so). In this world, more or less PostgreSQL functions are just a part of their applications. If they trust their client side applications, why they cannot trus

[HACKERS] function side effects

write? -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Hot Standby and DROP DATABASE

of max_standby_delay. So it seems at least the behavior is quite different from what the docs stats. Am I missing something here? -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-ha

Re: [HACKERS] Re: [COMMITTERS] pgsql: Write a WAL record whenever we perform an operation without

gt; necessary, that information is already in RewriteState, so I took that out. Are we going to bump up frontend/backend protocol version 3.0 to 3.x or some such? -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hac

[HACKERS] doc error

Hi, Can please someone fix this? I can fix other errors ocuured on plperl.sgml but I don't know how to do with this: openjade:plperl.sgml:290:31:X: reference to non-existent ID "PLPERL.USE_STRICT" -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php

Re: [HACKERS] Mammoth in Core?

ch you need to replace... quite difficult >* but if we have the plan, could do better -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp > > This page was a bit messy for someone who didn't attend the meeting to > &

[HACKERS] XQuery support

Query functionality from scratch. I'm wondering if other people reach the same conclusion as me, or is it a totaly impossible project? -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.post

[HACKERS] Re: [COMMITTERS] pgsql: Fix portalmem.c to avoid keeping a dangling pointer to a cached

lready in aborted state. Report and diagnosis by Tatsuo > Ishii, though this isn't exactly his proposed patch. > > Modified Files: > -- > pgsql/src/backend/utils/mmgr: > portalmem.c (r1.115 -> r1.116) > > (http://anoncvs.postgresql.org

Re: [HACKERS] AtAbort_Portsl problem

> Tatsuo Ishii writes: > > While ago, I reported a problem regarding exec_execute_message crash > > in transaction abort state if sync message issued right after parse, > > bind and execute message (which is normal if used with pgpool). After > > further investigation,

[HACKERS] AtAbort_Portsl problem

hedPlan) or belongs to the same one of portal heap meory, which will be dropped at the same time when the portal itself dropped. -- Tatsuo Ishii SRA OSS, Inc. Japan Index: src/backend/utils/mmgr/portalmem.c === RCS file: /cvsro

Re: [HACKERS] exec_execute_message crash

oryContextDelete in ReleaseCachedPlan. Also I defined CLOBBER_FREED_MEMORY in aset.c to fill with 0x7f the freed memory. Strange thing was portal->smts was not clobbered by 0x7f. It seems I have missed something here... -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] exec_execute_message crash

orize the memory context which it belongs to and we need add a new struct member to portal. I'm afraid this is an overkill... > It'd be nice to have a test case for this, hint hint ... Still working on... -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing lis

Re: [HACKERS] exec_execute_message crash

> Tatsuo Ishii wrote: > > ! if (!PortalIsValid(portal) || (PortalIsValid(portal) && portal->cleanup > > == NULL)) > > > > > > > Surely the second call to PortalIsValid() is redundant. > > if (( !PortalIsValid(portal)) ||

Re: [HACKERS] exec_execute_message crash

dest = DestRemoteExecute; portal = GetPortalByName(portal_name); ! if (!PortalIsValid(portal) || (PortalIsValid(portal) && portal->cleanup == NULL)) ereport(ERROR, (errcode(ERRCODE_UNDEFINED_CURSOR),

Re: [HACKERS] exec_execute_message crush

1) <=BE ParseComplete [null] > 21:41:39.443 (1) <=BE BindComplete [null] > 21:41:39.444 (1) <=BE RowDescription(1) > 21:41:39.444 (1) <=BE DataRow > 21:41:39.444 (1) <=BE CommandStatus(SELECT) > 21:41:39.454 (1) <=BE ErrorMessage(ERROR: syntax error at or near > &q

Re: [HACKERS] exec_execute_message crush

> (In any case, some kind of quick lobotomy in libpq would be easier > than writing a standalone test program, no?) Sounds nice idea. -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] exec_execute_message crush

, but > I vaguely recall something like that exists. It seems we can't get libpq to do it. libpq does not provide a function which can execute bind alone. In my understanding PQexecPrepared does bind + execute. -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing

Re: [HACKERS] exec_execute_message crush

nt":-) Let me try... Another idea is a "packet recorder", which could record packets from pgpool to PostgreSQL and replay them. I don't remember at present, but I vaguely recall something like that exists. -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing

Re: [HACKERS] exec_execute_message crush

> Tatsuo Ishii writes: > > It seems the source of the problem is, exec_execute_message tries to > > execute unamed portal which has unnamed statement which has already > > gone. > > Could we see an actual test case? If you don't mind to use pgpool, it would be p

[HACKERS] exec_execute_message crush

if prior parse, bind etc. failed, I think. The crush happens PostgreSQL 8.3.8, 8.3.9 and 8.4.2. Any thought? -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] no lo_import(text, oid) document

> Tatsuo Ishii writes: > > BTW, why don't lo_creat, lo_create, lo_unlink, lo_import and lo_export > > server side function's document appear in the "Chapter 9. Functions and > > Operators" section? > > Because large objects have their very own cha

[HACKERS] no lo_import(text, oid) document

and lo_export server side function's document appear in the "Chapter 9. Functions and Operators" section? Shall I add them? -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Windows x64 [repost]

ce > post, or the other way around :-) And it's very useful to know that > one set of eyes have been on it already. Ok, next time I will do that. As I said before, I'm not a good Windows programmer at all and hesitated to say that "Trust me, I have reviewd his patches":-) --

Re: [HACKERS] [PATCH] Windows x64 [repost]

rsion would give a boost > > perception-wise > > I'm also very interested - despite the fact it'll cause me a boatload > of work to produce a new set of installers for this architecture! Sorry for this:-) -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hacker

Re: [HACKERS] [PATCH] Windows x64 [repost]

roup:-) But I'd like to > > know how other people are interested in the patches. > > I am very interested. A 64bit-Windows-Version would give a boost > perception-wise > > (I know the technical arguments about usefullness or not, but > perception is different and oft

Re: [HACKERS] [PATCH] Windows x64 [repost]

publishes the patches. (I and he are working for the same company). However I'm not a Windows programmer by no means. So my suggestion was mainly for designs... -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To mak

Re: [HACKERS] [PATCH] Windows x64 [repost]

> Tatsuo Ishii wrote: > > Now that Greg is going to close the Nov Commit Festa, I think he is > > requesting initial reviews for the patches. > > > > While Magnus might take a look anyway, in general we'll all be taking a > break from review until January

Re: [HACKERS] [PATCH] Windows x64 [repost]

reviews for the patches. Did you have a chance to review the Windows x64 patches? -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Application name patch - v4

ch. TP monitor has its own API and it is at liberty behave what it wants. Don't get me wrong. I would not say TP monitor is useless, rather it has very usefull use cases I think. However, pushing its semantics about sessions to PostgreSQL side, would be counterproductive for both TP monitor and

Re: [HACKERS] Summary and Plan for Hot Standby

cquire AccessShareLocks. If we allowed higher locks > > we might need to do deadlock detection, which would add more complexity. > > But we *do* allow higher locks than AccessShareLocks, as Tatsuo-sans > example shows. Is that a bug? Sorry for confusion. My example is under normal P

Re: [HACKERS] Summary and Plan for Hot Standby

objsubid | virtualtransaction | 1/101699 pid| 28020 mode | RowExclusiveLock granted| t test=# select relname from pg_class where oid = 1574918; -[ RECORD 1 ] relname | t1 -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing

Re: [HACKERS] Summary and Plan for Hot Standby

currently considered to be disallowed during read > only transactions. That might be able to change if the underlying > physical operation were write-free. Thanks for explanation. -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] Summary and Plan for Hot Standby

> Tatsuo Ishii wrote: > > Just a question: > > > > - Does Hot Standby allow to use prepared query (not prepared > > transaction) in standby? I mean: Parse message from frontend can be > > accepted by standby? > > Yes. In my understanding, Parse will aq

Re: [HACKERS] Summary and Plan for Hot Standby

Just a question: - Does Hot Standby allow to use prepared query (not prepared transaction) in standby? I mean: Parse message from frontend can be accepted by standby? - Can we create tempory tables in standby? -- Tatsuo Ishii SRA OSS, Inc. Japan > After some time thinking about the best

Re: [HACKERS] Typed tables

required by the standard or are we going past the standard? +1. I'd like to hear from Peter why this is neccessary in the first place. -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Architecture of walreceiver (Streaming Replication)

ases. But I think that it's sufficient to provide that as > contrib or pgfoundry tool. Not need to provide that in core. > The communication interface to walsender is going to be > provided as libpq, so it's not difficult to implement such > a stand-alone tool. +1. I agree wit

Re: [HACKERS] misleading comments in pgbench

has never pretended * to be fully TPC-B compliant anyway, we stick with the * historical behavior. -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Idle connection timeout

as similar functionality too. See client_idle_limit directive in the pgpool-II configuration file. -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pgbench hard coded constants

to inconsistent results (select sum(abalance) from > > pgbench_accounts does not equal sum(delta) from pgbench_history), while > > with the patch they are equal. > > Looks good. If there's no objection, I will commit into CVS HEAD. Done. Thanks Jeff! -- Tatsuo Ishii SRA OSS, Inc. Japan

Re: [HACKERS] pgbench hard coded constants

accounts does not equal sum(delta) from pgbench_history), while > with the patch they are equal. Looks good. If there's no objection, I will commit into CVS HEAD. -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make ch

Re: [HACKERS] ecpg build failed on CVS HEAD

> > In my understanding src/interfaces/ecpg/preproc/parser.c linkes to > > src/backend/parser/parser.c. So they are identical, no? > > They haven't been identical since 8.2. It seems my working files for ecpg are confused. Removing symlink and cvs update fixed my problem.

Re: [HACKERS] ecpg build failed on CVS HEAD

> No, it doesn't ... but maybe you've somehow overwritten > src/interfaces/ecpg/preproc/parser.c with src/backend/parser/parser.c ? In my understanding src/interfaces/ecpg/preproc/parser.c linkes to src/backend/parser/parser.c. So they are identical, no? -- Tatsuo Ishii SRA

[HACKERS] ecpg build failed on CVS HEAD

t+0xb0): In function `pg_parse_string_token': : undefined reference to `elog_finish' collect2: ld returned 1 exit status make: *** [ecpg] Error 1 -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

[HACKERS] PQexecPrepared() behavior

;Executing the statement...\n"); res = PQexecPrepared(conn,"",1,param_values,NULL,NULL,0); switch(PQresultStatus(res)) { case PGRES_COMMAND_OK: case PGRES_TUPLES_OK: break; default:

Re: [HACKERS] CommitFest Status Summary - 2009-08-03

e allowed to commit the > pacthes. Patch committed. -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] CVS Head parser error?

Sorry for noise. I regenerated scan.c and gram.c and now everything works fine. -- Tatsuo Ishii SRA OSS, Inc. Japan > I got following with CVS Head parser. I'm using bison 2.1 and flex > 2.5.35. Am I missing something? > > make[3]: Entering directory > `/usr/local/src/pgs

[HACKERS] CVS Head parser error?

I got following with CVS Head parser. I'm using bison 2.1 and flex 2.5.35. Am I missing something? make[3]: Entering directory `/usr/local/src/pgsql/current/pgsql/src/backend/parser' gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -I. -I../../../src/include

Re: [HACKERS] CommitFest Status Summary - 2009-08-03

> > Personally I was thinking of multi-threaded pgbench as being > > Tatsuo-san's to commit, since that's his code originally. > > Ah see well that's why I post these summaries... :-) Thanks. I consider it a great honor to be allowed to commit the pacthes. --

Re: [HACKERS] CommitFest 2009-07 is Now Closed

Robert, Tsutomu was asking to add his patches to July commit festa: http://archives.postgresql.org/pgsql-hackers/2009-07/msg00782.php But it does not seem all subsequent replies agree that. What shall he do? Just waits for next commit festa? -- Tatsuo Ishii SRA OSS, Inc. Japan > The time

Re: [HACKERS] CommitFest 2009-07 is Now Closed

gt; > Adding a patch to the CommitFest doesn't require permission. It's > just asking that the patch be reviewed, not guaranteeing anything. > Patch authors are supposed to add patches to the commitfest site > themselves, but I will add this one. Thanks! -- Tatsuo Ishii SRA OS

Re: [HACKERS] 8.4b2 tsearch2 strange error

more strange behavior. I'm not entirely convinced that this is the > only problem ... Thanks for investigating the problem. Using CVS HEAD and reindexing has solved the problems I reported. On Monday I will ask my engineers try the CVS HEAD and do more operations to see if any strange th

Re: [HACKERS] 8.4b2 tsearch2 strange error

, to_tsvector(E'%s')) DELETE FROM msginfo WHERE msg_sid = %lu DELETE FROM msginfo WHERE msg_sid IN (SELECT msg_sid FROM msginfo EXCEPT SELECT msg_sid FROM msg_folderinfo) So no exotic things appear... -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.4b2 tsearch2 strange error

, msg_date, folder_id, msgnum FROM msginfo LEFT JOIN msg_folderinfo USING (msg_sid) WHERE plainto_tsquery(E'tsearch') @@ body_index; ERROR: tuple offset out of range: 609 -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.4b2 tsearch2 strange error

t;tuple offset out of range" errors. Maybe this is due to the difference how the index is physically organized. I will uplaod physical database cluster. -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscri

Re: [HACKERS] 8.4b2 tsearch2 strange error

e not customizing default_text_search_config. I'm not think of any nondefault configuration settings. -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 8.4b2 tsearch2 strange error

folder_id, msgnum FROM msginfo LEFT JOIN msg_folderinfo USING (msg_sid) WHERE plainto_tsquery(E'pitr') @@ body_index -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] 8.4b2 tsearch2 strange error

can on msginfo_body_index (cost=0.00..4.59 rows=1 width=0) Index Cond: (to_tsquery('test'::text) @@ body_index) (4 rows) -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Updated Korean character set mappings

s. > This brings the UHC mapping in line with Microsoft's and GNU iconv's. Patch committed to CVS Head. Thanks. -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Updated Korean character set mappings

s. > This brings the UHC mapping in line with Microsoft's and GNU iconv's. Looks good. I will commit this if there's no objection. -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Unicode string literals versus the world

gt; > > > I could live with either. Wikipedia says: "The characters outside the > > first plane usually have very specialized or rare use." For years we > > rejected all characters beyond the first plane, and while that's fixed > > now, the volume of

Re: [HACKERS] Unicode string literals versus the world

first plane usually have very specialized or rare use." For years we > rejected all characters beyond the first plane, and while that's fixed > now, the volume of complaints wasn't huge. I you mean "first plane" as BMP (i.e. 16bit range), above is not true for PostgreSQL 7.3 or later at least. -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] DISCARD ALL failing to acquire locks on pg_listen

Thanks for valuable info! I'm going to add a caution to pgpool-II's docs. "DISCARD ALL will cause serious performance degration". -- Tatsuo Ishii SRA OSS, Inc. Japan > Hi everyone, > > I've been recently testing PostgreSQL 8.3.4 (upgrade to 8.3.6 is &

Re: [HACKERS] temporarily stop autovacuum

> all relations to false. Thanks. Maybe it will be easier to talk to the autovacuum launcher daemon process directly? I will look in to the code. -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: htt

[HACKERS] temporarily stop autovacuum

Hi, Is there any way to stop autovacuum temporarily?(other than edit postgresql.conf and reload it) Pgpool-II does not want autovacuum running while doing "onlie recovery". -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To ma

[HACKERS] error code 25001

. So my question is, an error code is used for both an error condition *and* a warning: is this normal? -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] contrib Japanese README

, I will commit the removal into CVS Head. > > Agreed. I assume the content is now being translated to Japanese as > part of the SGML docs. Yes, the content is provided as English SGML files and then they are translated into Japanese by JPUG. So we would lose nothing actually. -- Tatsuo Ish

[HACKERS] contrib Japanese README

files (Japanese docs are provided by JPUG). For these reasons I propose to remove them. Unless there's an objection, I will commit the removal into CVS Head. -- Tatsuo Ishii SRA OSS, Inc. Japan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] Lock conflict behavior?

share lock at the very eary stage in > strating up. Another concern is, two phase commit. If a 2PC transaction includes DDL, access share lock for pg_class is left. Someone comes with alter table pg_class and tries to hold an exclusive lock. After this all SELECT and autovacuum will stop beca

Re: [HACKERS] Lock conflict behavior?

and issue the ALTER TABLE > at that time. In the scenario I mentioned, even a new connection cannot be made to the database since the backend need to initialize relcache by reading system catlogs with access share lock at the very eary stage in strating up. -- Tatsuo Ishii SRA OSS, Inc. Japa

<    3   4   5   6   7   8   9   10   11   12   >