Re: [PATCHES] initdb of regression test failed.
Hiroshi Saito [EMAIL PROTECTED] wrote: Ah Ok, Please check it. Your patch looks useful to prevent mismatch of encoding and locale on Windows, but I found there is a limitation that user will not able to specify locale. I added an alternative of nl_langinfo(CODESET) for Win32. Please check following commands: initdb --encoding=EUC_jp --locale=Japanese_Japan.932 vs. initdb --encoding=EUC_jp --locale=Japanese_Japan.20932 One problem is that user need to know codepage numbers. It might be possible to replace the default codepage to server encodings automatically if we have a mapping table from encoding to codepage. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center chklocale-v2.patch Description: Binary data ---(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
Re: [PATCHES] ecpg DllMain fix
On Wed, Oct 03, 2007 at 11:54:44AM +0900, ITAGAKI Takahiro wrote: Here is a patch to remove DllMain from libecpg on Win32 build. I brought the initialization routine from libpq and implemented pthread_once() using a lock that serializes all pthread_once calls. I don't have msvc build environment, but I hope it will fix the build failure on it. We will see. Since it doesn't break my linux system I committed the patch. If anyone notices a problem please tell me. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] ecpg thread-safe descriptor
On Tue, Oct 02, 2007 at 04:07:06PM -0400, Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Michael Meskes wrote: So, does an explicit export list help? If so I'm all for it. There is no need to export all symbols. I always tried to keep the number of symbols that get exported but are not needed low. So this will give the best result possible. Yeah, it does seem to fix it. That's very good news. If Michael can put together an export list soon then we'll be in good shape. I will work on it asap. Michael: you should bump the major version number of ecpglib when you do this. Removing the not-officially-exported visible symbols *is* an ABI break. You may think there isn't anything depending on them, but remember how we thought that (twice) for libpq too. Bumping the major version number will be cheap insurance against complaints later. ecpg received a bump from 5 to 6 in this release anyway because of some other ABI changes, so at least here we're fine. :-) Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[PATCHES] Doc update: ALTER SEQUENCE name RENAME TO can be rolled back
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com Index: doc/src/sgml/ref/alter_sequence.sgml === RCS file: /home/hlinnaka/pgcvsrepository/pgsql/doc/src/sgml/ref/alter_sequence.sgml,v retrieving revision 1.17 diff -c -r1.17 alter_sequence.sgml *** doc/src/sgml/ref/alter_sequence.sgml 3 Jul 2007 01:30:35 - 1.17 --- doc/src/sgml/ref/alter_sequence.sgml 3 Oct 2007 09:33:38 - *** *** 224,230 same sequence, commandALTER SEQUENCE/command's effects on the sequence generation parameters are never rolled back; those changes take effect immediately and are not reversible. However, !the literalOWNED BY/ and literalSET SCHEMA/ clauses are ordinary catalog updates and can be rolled back. /para --- 224,230 same sequence, commandALTER SEQUENCE/command's effects on the sequence generation parameters are never rolled back; those changes take effect immediately and are not reversible. However, !the literalOWNED BY/, literalSET SCHEMA/ and literalRENAME/ clauses are ordinary catalog updates and can be rolled back. /para ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] ecpg DllMain fix
On Wed, Oct 03, 2007 at 11:13:27AM +0200, Magnus Hagander wrote: Heh, I was about to review that. I'll try to get to it right after lunch. Thanks and sorry for jumping the gun. If it doesn't work we can remove it easily. I'm working on an export list atm. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] ecpg DllMain fix
On Wed, Oct 03, 2007 at 12:19:14PM +0200, Michael Meskes wrote: On Wed, Oct 03, 2007 at 11:13:27AM +0200, Magnus Hagander wrote: Heh, I was about to review that. I'll try to get to it right after lunch. Thanks and sorry for jumping the gun. If it doesn't work we can remove it easily. Np. It passes compile. Rebuilding my full tree now to try to work on making the regression tests actually be able to test it. I'm working on an export list atm. Good. I think we want that regardless of things being fixed by removing Dllmain. //Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] ecpg DllMain fix
On Wed, Oct 03, 2007 at 12:22:41PM +0200, Magnus Hagander wrote: It passes compile. Rebuilding my full tree now to try to work on making the regression tests actually be able to test it. Sounds good. :-) I'm working on an export list atm. Good. I think we want that regardless of things being fixed by removing Dllmain. Just committed. I also renamed the functions that are not exported to make this job easier. Should there be a problem with this it should only be a missed rename. However the new sources successfully run through the regression suite on my Linux system with and without multithreading. As for the export list I copied the stuff from libpq, it's untested on all other archs. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] ecpg DllMain fix
On Wed, Oct 03, 2007 at 01:13:58PM +0200, Michael Meskes wrote: On Wed, Oct 03, 2007 at 12:22:41PM +0200, Magnus Hagander wrote: It passes compile. Rebuilding my full tree now to try to work on making the regression tests actually be able to test it. Sounds good. :-) At least we're proceeding. Going further, all the new threading tests fail on msvc. Haven't investigated why yet, but will do. I'm working on an export list atm. Good. I think we want that regardless of things being fixed by removing Dllmain. Just committed. I also renamed the functions that are not exported to make this job easier. Should there be a problem with this it should only be a missed rename. However the new sources successfully run through the regression suite on my Linux system with and without multithreading. As for the export list I copied the stuff from libpq, it's untested on all other archs. Ok. I'll take a look at that on msvc when I'm done with the reg tests, but I'll try to get those running first. //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] ecpg DllMain fix
On Wed, Oct 03, 2007 at 01:13:58PM +0200, Michael Meskes wrote: Just committed. I also renamed the functions that are not exported to make this job easier. Should there be a problem with this it should only be a missed rename. However the new sources successfully run through the regression suite on my Linux system with and without multithreading. As for the export list I copied the stuff from libpq, it's untested on all other archs. I've update the msvc build to deal with this, and it works. However, shouldn't we be doing it for other ECPG libraries as well? //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] ecpg DllMain fix
On Wed, Oct 03, 2007 at 02:27:20PM +0200, Magnus Hagander wrote: However, shouldn't we be doing it for other ECPG libraries as well? Done. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] ecpg DllMain fix
On Wed, Oct 03, 2007 at 03:22:12PM +0200, Michael Meskes wrote: On Wed, Oct 03, 2007 at 02:27:20PM +0200, Magnus Hagander wrote: However, shouldn't we be doing it for other ECPG libraries as well? Done. Added to MSVC build. //Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] Doc update: ALTER SEQUENCE name RENAME TO can be rolled back
Heikki Linnakangas [EMAIL PROTECTED] writes: those changes take effect immediately and are not reversible. However, !the literalOWNED BY/ and literalSET SCHEMA/ clauses are ordinary catalog updates and can be rolled back. those changes take effect immediately and are not reversible. However, !the literalOWNED BY/, literalSET SCHEMA/ and literalRENAME/ clauses are ordinary catalog updates and can be rolled back. Good catch --- applied along with some other fixes. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] OpenSSL Applink
Magnus Hagander wrote: Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: On Mon, Oct 01, 2007 at 10:51:01AM -0400, Tom Lane wrote: I'd vote for backpatching, but only as far as 8.2, seeing that we're abandoning the older branches on Windows. Should we backpatch a version of it to previous versions that does just the error stack manipulation, or just ignore on the grounds that nobody has reported the problem there (it's there, but it's a lot more narrow - I know it's there, but I havent' been able to provoket it due to not knowing enough about setting up certificate chains and such) That's only a cosmetic problem (wrong error message), right? I'd vote for no backpatch, at least for now --- I'd rather see this change get through beta testing first. Anytime you're fooling with interactions with some other package, the risk of portability issues is high. Right. Applied to HEAD. Will wait for a buildfarm cycle to make sure it doesn't kill anything else then try to backport to 8.2 (patch didn't apply cleanly to it) I guess you guys already found a solution that works, but there's yet another function, BIO *BIO_new_mem_buf(void *data, int len), that we could use. We could open and read the file all by ourselves into memory, then call BIO_new_mem_buf and pass that to PEM_read_X509. No need to pass around file pointers, and we could handle any file I/O errors ourselves. Presumably certificates are never very big, so reading it all in memory shouldn't be a problem. BIO_new_mem_buf was introduced in OpenSSL 0.9.7. What versions do we support? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(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
Re: [PATCHES] initdb of regression test failed.
Hi. - Original Message - From: ITAGAKI Takahiro [EMAIL PROTECTED] Hiroshi Saito [EMAIL PROTECTED] wrote: Ah Ok, Please check it. Your patch looks useful to prevent mismatch of encoding and locale on Windows, but I found there is a limitation that user will not able to specify locale. I added an alternative of nl_langinfo(CODESET) for Win32. Please check following commands: initdb --encoding=EUC_jp --locale=Japanese_Japan.932 vs. initdb --encoding=EUC_jp --locale=Japanese_Japan.20932 One problem is that user need to know codepage numbers. It might be possible to replace the default codepage to server encodings automatically if we have a mapping table from encoding to codepage. Yes, I think your approach looks very good. Then, It seems that it is necessary to consider an original initial value problem again. I consider a document publication or management. Anyway, Thanks. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] initdb of regression test failed.
ITAGAKI Takahiro [EMAIL PROTECTED] writes: Your patch looks useful to prevent mismatch of encoding and locale on Windows, but I found there is a limitation that user will not able to specify locale. I added an alternative of nl_langinfo(CODESET) for Win32. Applied with small correction --- it looked like you'd put in the wrong PG_ENC code for GBK and BIG5. Not terribly important since we'd reject them anyway, but we might as well reject with the correct error message. This still leaves the policy decision of whether we want to have initdb assume -E UTF8 --no-locale if it sees the current locale has an unusable encoding. I'm not really happy with that idea because it would disable localization of messages. I think what we want, at least on Windows, is to switch to the corresponding locale that uses UTF8. Is there a simple way to do that? Or at least some simple recipe we can put into the documentation? If you get this sort of error, use this --locale setting... regards, tom lane ---(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
Re: [PATCHES] OpenSSL Applink
Heikki Linnakangas [EMAIL PROTECTED] writes: I guess you guys already found a solution that works, but there's yet another function, BIO *BIO_new_mem_buf(void *data, int len), that we could use. We could open and read the file all by ourselves into memory, then call BIO_new_mem_buf and pass that to PEM_read_X509. No need to pass around file pointers, and we could handle any file I/O errors ourselves. Presumably certificates are never very big, so reading it all in memory shouldn't be a problem. BIO_new_mem_buf was introduced in OpenSSL 0.9.7. What versions do we support? This seems like a good idea. To judge from the release history at http://www.openssl.org/news/ the OpenSSL boys stopped supporting 0.9.6 in 2004, so I figure we don't have to support it either. But 0.9.7 is still a live release branch, so it'd be good if we could play nice with it. http://www.openssl.org/docs/crypto/BIO_s_mem.html regards, tom lane ---(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 to the mailing list cleanly
Re: [PATCHES] OpenSSL Applink
Tom Lane wrote: Heikki Linnakangas [EMAIL PROTECTED] writes: I guess you guys already found a solution that works, but there's yet another function, BIO *BIO_new_mem_buf(void *data, int len), that we could use. We could open and read the file all by ourselves into memory, then call BIO_new_mem_buf and pass that to PEM_read_X509. No need to pass around file pointers, and we could handle any file I/O errors ourselves. Presumably certificates are never very big, so reading it all in memory shouldn't be a problem. BIO_new_mem_buf was introduced in OpenSSL 0.9.7. What versions do we support? This seems like a good idea. To judge from the release history at http://www.openssl.org/news/ the OpenSSL boys stopped supporting 0.9.6 in 2004, so I figure we don't have to support it either. But 0.9.7 is still a live release branch, so it'd be good if we could play nice with it. http://www.openssl.org/docs/crypto/BIO_s_mem.html Not sure it buys us much more than we already have. Sure, we can handle file I/O. But we still can't handle errors in the parsing of the file. I think that if we can open the file, then the chance that we fail to read it is extremely small, compared to the chance that we get a parsing error. //Magnus ---(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 to the mailing list cleanly
Re: [PATCHES] initdb of regression test failed.
Hi. regression test surely goes wrong.! hedule --multibyte=SQL_ASCII --load-language=plpgsql == creating temporary installation== == initializing database system == pg_regress: initdb failed Examine ./log/initdb.log for the reason. Command was: C:/MinGW/home/hiroshi/pgsql/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/initdb -D C:/MinGW/home/hiroshi/pgsql/src/test/regress/./tmp_check/data -L C:/MinGW/home/hiroshi/pgsql/src/test/regress/./tmp_check/install//usr/local/pgsql/share --noclean ./log/initdb.log 21 make[2]: *** [check] Error 2 make[2]: Leaving directory `/home/hiroshi/pgsql/src/test/regress' make[1]: *** [check] Error 2 make[1]: Leaving directory `/home/hiroshi/pgsql/src/test' make: *** [check] Error 2 -initdb.log- Running in noclean mode. Mistakes will not be cleaned up.^M The files belonging to this database system will be owned by user hiroshi.^M This user must also own the server process.^M ^M The database cluster will be initialized with locale Japanese_Japan.932.^M initdb: locale Japanese_Japan.932 requires unsupported encoding SJIS^M Encoding SJIS is not allowed as a server-side encoding.^M Rerun initdb with a different locale selection.^M Running in noclean mode. Mistakes will not be cleaned up.^M - after the patch.. == shutting down postmaster == server stopped === All 112 tests passed. === Anyway, It surely fails now.:-( Regards, Hiroshi Saito pg_regress_patch Description: Binary data ---(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 to the mailing list cleanly
Re: [PATCHES] initdb of regression test failed.
Oops, patch of pg_regress.c should be disregarded. Sorry, I think this is desirable. Hi. regression test surely goes wrong.! hedule --multibyte=SQL_ASCII --load-language=plpgsql == creating temporary installation== == initializing database system == pg_regress: initdb failed Examine ./log/initdb.log for the reason. Command was: C:/MinGW/home/hiroshi/pgsql/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/initdb -D C:/MinGW/home/hiroshi/pgsql/src/test/regress/./tmp_check/data -L C:/MinGW/home/hiroshi/pgsql/src/test/regress/./tmp_check/install//usr/local/pgsql/share --noclean ./log/initdb.log 21 make[2]: *** [check] Error 2 make[2]: Leaving directory `/home/hiroshi/pgsql/src/test/regress' make[1]: *** [check] Error 2 make[1]: Leaving directory `/home/hiroshi/pgsql/src/test' make: *** [check] Error 2 -initdb.log- Running in noclean mode. Mistakes will not be cleaned up.^M The files belonging to this database system will be owned by user hiroshi.^M This user must also own the server process.^M ^M The database cluster will be initialized with locale Japanese_Japan.932.^M initdb: locale Japanese_Japan.932 requires unsupported encoding SJIS^M Encoding SJIS is not allowed as a server-side encoding.^M Rerun initdb with a different locale selection.^M Running in noclean mode. Mistakes will not be cleaned up.^M - after the patch.. == shutting down postmaster == server stopped === All 112 tests passed. === Anyway, It surely fails now.:-( Regards, Hiroshi Saito regress_patch Description: Binary data ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Use of postmaster
On 10/4/07, Tom Lane [EMAIL PROTECTED] wrote: Brendan Jurd [EMAIL PROTECTED] writes: Now that we've renamed the server binary to postgres, what is the status on use of the name postmaster? Is it now deprecated? And if not, is there any point in keeping it around? We should replace it by terms like server in contexts where it's not actually important to the reader which process is involved, but I think Peter's hit most of them already ... Looks like Peter got the sgml sources pretty well cleaned up, but didn't touch the FAQs. The attached patch replaces some more references to postmaster in the FAQs. Per Tom's guidance, I only replaced those references where I felt a distinction between the postmaster and its children wasn't important to the reader. Thanks for your time, BJ Index: doc/FAQ === RCS file: /projects/cvsroot/pgsql/doc/FAQ,v retrieving revision 1.433 diff -c -r1.433 FAQ *** doc/FAQ 27 Sep 2007 06:14:46 - 1.433 --- doc/FAQ 3 Oct 2007 23:43:08 - *** *** 423,432 3.5) Why do I get Sorry, too many clients when trying to connect? !You have reached the default limit is 100 database sessions. You need !to increase the postmaster's limit on how many concurrent backend processes it can start by changing the max_connections value in !postgresql.conf and restarting the postmaster. 3.6) What is the upgrade process for PostgreSQL? --- 423,432 3.5) Why do I get Sorry, too many clients when trying to connect? !You have reached the default limit of 100 database sessions. You need !to increase the server's limit on how many concurrent backend processes it can start by changing the max_connections value in !postgresql.conf and restarting the server. 3.6) What is the upgrade process for PostgreSQL? *** *** 753,759 You probably have run out of virtual memory on your system, or your kernel has a low limit for certain resources. Try this before starting !postmaster: ulimit -d 262144 limit datasize 256m --- 753,759 You probably have run out of virtual memory on your system, or your kernel has a low limit for certain resources. Try this before starting !the server: ulimit -d 262144 limit datasize 256m Index: doc/FAQ_AIX === RCS file: /projects/cvsroot/pgsql/doc/FAQ_AIX,v retrieving revision 1.21 diff -c -r1.21 FAQ_AIX *** doc/FAQ_AIX 6 Dec 2006 15:45:30 - 1.21 --- doc/FAQ_AIX 3 Oct 2007 23:43:10 - *** *** 301,307 The overall cause of all these problems is the default bittedness and ! memory model used by the postmaster process. By default, all binaries built on AIX are 32-bit. This does not depend upon hardware type or kernel in use. These 32-bit processes --- 301,307 The overall cause of all these problems is the default bittedness and ! memory model used by the server process. By default, all binaries built on AIX are 32-bit. This does not depend upon hardware type or kernel in use. These 32-bit processes *** *** 327,336 build, but not run, 64-bit binaries. If a 32-bit binary is desired, set LDR_CNTRL to MAXDATA=0xn000, ! where 1 = n = 8, before starting the postmaster and try different values and postgresql.conf settings to find a configuration that works satisfactorily. This use of LDR_CNTRL tells AIX that you want the ! postmaster to have $MAXDATA bytes set aside for the heap, allocated in 256MB segments. When you find a workable configuration, ldedit can be used to modify --- 327,336 build, but not run, 64-bit binaries. If a 32-bit binary is desired, set LDR_CNTRL to MAXDATA=0xn000, ! where 1 = n = 8, before starting the postgres server and try different values and postgresql.conf settings to find a configuration that works satisfactorily. This use of LDR_CNTRL tells AIX that you want the ! server to have $MAXDATA bytes set aside for the heap, allocated in 256MB segments. When you find a workable configuration, ldedit can be used to modify Index: doc/FAQ_CYGWIN === RCS file: /projects/cvsroot/pgsql/doc/FAQ_CYGWIN,v retrieving revision 1.2 diff -c -r1.2 FAQ_CYGWIN *** doc/FAQ_CYGWIN 15 Oct 2004 16:18:35 - 1.2 --- doc/FAQ_CYGWIN 3 Oct 2007 23:43:10 - *** *** 30,37 3a. Start cygserver for shared memory support. To do this, enter the command /usr/sbin/cygserver . This program ! needs to be running anytime you start the PostgreSQL server ! (postmaster) or initialize a database (initdb). 3b. Use the initdb
Re: [PATCHES] initdb of regression test failed.
Hiroshi Saito [EMAIL PROTECTED] wrote: regression test surely goes wrong.! This fix does nothing against the regression failure. It is probably reasonable to choose UTF-8 as a server encoding when we cannot support the encoding of the current locale. A remaining issue is which we should use no-locale, locale of another encoding, or reporting error then. At least on Windows, locale of another encoding works correctly because we've already had some Windows-specific hacks. (try grep MultiByteToWideChar) In fact, we can accept options like: initdb -E UTF8 --locale=Japanese_Japan.932 -- CP932 is SJIS in nature I'll suggest to use UTF8 if the encoding is UTF-8 or NOT specified and we don't support the locale encoding on Windows, i.e. locale is always enabled on regression tests. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] initdb of regression test failed.
I wrote: I'll suggest to use UTF8 if the encoding is UTF-8 or NOT specified and we don't support the locale encoding on Windows, i.e. locale is always enabled on regression tests. Here is a patch to do it on Windows. 1. Use UTF-8 if the locale encoding is not available for server. 2. Allow mismatch between server and locale encodings if the server encoding is UTF-8. I succeeded to run regression test on Japanese version of Windows with the patch, but please test it on other language versions. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center utf8_win32.patch Description: Binary data ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] initdb of regression test failed.
Hi. Um, I thinks the examination material of 8.4 by the reason for changing the feature. Of course, your proposal can be considered to obtain one solution. Then, discussion is required more. I feel that it is dangerous for 8.3 Regards, Hiroshi Saito I wrote: I'll suggest to use UTF8 if the encoding is UTF-8 or NOT specified and we don't support the locale encoding on Windows, i.e. locale is always enabled on regression tests. Here is a patch to do it on Windows. 1. Use UTF-8 if the locale encoding is not available for server. 2. Allow mismatch between server and locale encodings if the server encoding is UTF-8. I succeeded to run regression test on Japanese version of Windows with the patch, but please test it on other language versions. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] initdb of regression test failed.
ITAGAKI Takahiro [EMAIL PROTECTED] writes: In fact, we can accept options like: initdb -E UTF8 --locale=Japanese_Japan.932 -- CP932 is SJIS in nature Hmm, but does that really work safely? I think varstr_cmp() does work, because it forces our data into wchar format and then calls wcscoll(). The thing that scares me is that various random other operating-system calls might deliver strings in an unexpected encoding. We've been through similar problems with timezone names reported by strftime, for example. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
