Re: [PATCHES] Loose check was corrected of win32.mak.
On Tue, Oct 02, 2007 at 02:20:16PM +0900, Hiroshi Saito wrote: Hi Magnus. Loose check was corrected... and, It notifies an intelligible error message. + !MESSAGE nmake ended + !ERROR Make aorted. Apart from the spelling error on the second line, do we need the first line at all? It kind of says the same thing, but does nmake require a fixed number of rows or so? If not, I'll just take that away before committing. //Magnus ---(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 02:38:09PM +0900, ITAGAKI Takahiro wrote: Here is a patch to fix thread-safety of SQL DESCRIPTOR in ecpg. The global variable 'all_descriptors' is split into per-thread vars. There was another idea of splitting into per-connection vars, but I did not do that because there are allocating descriptors before connection and deallocating after disconnection in the regression test. The attached descriptor.pgc is a test case for the issue. It is not included into regression test of ecpg. (haven't looked at the patch itself) If this change is acceptable to be applied to HEAD, I'll start backporting recent fixes (prepared statement, memory allocation and descriptor) to 8.2 (and older versions if possible). Are you sure we should backport this to 8.2 and earlier? It's fairly large changes, and not necessarily entirely straightforward (for example, the buildfarm is still partially broken from the earlier ones not being portable enough). I think this can be considered a new feature and not just a plain bugfix, so it should probably only go into HEAD. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Function structure in formatting.c
I noticed an editing error in the patch I originally submitted; it
defined the same debugging macro twice.
I've attached a fresh copy of the patch against the current HEAD with
the fix included.
Cheers,
BJ
On 8/11/07, Brendan Jurd [EMAIL PROTECTED] wrote:
Hello,
As discussed on -hackers, I've done some refactoring work on
backend/utils/adt/formatting.c, in an attempt to make the code a bit
more intelligible before improving handling of bogus formats.
This is purely a refactor. The functionality of the file hasn't
changed; it does the same job as before, but it does it in ~200 fewer
lines and ~3.5k fewer characters. The clarity of code is greatly
improved. Sadly, performance appears to be unchanged.
Summary of changes:
* Did away with dch_global, dch_date and dch_time.
* Replaced DCH_processor with two new functions DCH_to_char and
DCH_from_char, which now do all the work previously done by
dch_{global,date,time}.
* Removed the 'action' field from the KeyWord struct as it is no longer
useful.
* Changed the type of the 'character' field in the FormatNode struct
to char, because ... that's what it is. The original choice of 'int'
seems to have been an error.
* Removed commented-out function declaration for is_acdc. According
to CVS annotate, this hasn't been in use since sometime in the early
Cretaceous period, and in any case I don't know why you'd want to
check whether a string was the rock band AC/DC. =)
* Reworded some of the comments for clarity.
* Didn't touch any of the number formatting routines.
This compiles cleanly on x86 gentoo and passes check, installcheck and
installcheck-parallel.
Thanks for your time,
BJ
formatting-refactor_1.diff.gz
Description: GNU Zip compressed data
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [PATCHES] ecpg thread-safe descriptor
Magnus Hagander [EMAIL PROTECTED] wrote: Are you sure we should backport this to 8.2 and earlier? It's fairly large changes, and not necessarily entirely straightforward (for example, the buildfarm is still partially broken from the earlier ones not being portable enough). Almost portability issues come from Windows, but ecpg in 8.2 only support thread-safety on pthread, not on Win32. So backporting is easier than expected because we can neglect Windows. I want thread-safe ecpg *NOW* and cannot wait for 8.3 release... At any rate, I'll fix it at hand and report it if it works well. BTW, do we need to distribute ecpg with server (or client library) ? If it was a separate product, I think we will be able to maintain them more flexiblly, just like libpqxx or JDBC. 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] ecpg thread-safe descriptor
On Tue, Oct 02, 2007 at 02:38:09PM +0900, ITAGAKI Takahiro wrote: Here is a patch to fix thread-safety of SQL DESCRIPTOR in ecpg. ... Applied to CVS HEAD. Thanks. 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 5: don't forget to increase your free space map settings
Re: [PATCHES] Loose check was corrected of win32.mak.
From: Magnus Hagander [EMAIL PROTECTED] + !MESSAGE nmake ended + !ERROR Make aorted. Apart from the spelling error on the second line, do we need the first line at all? It kind of says the same thing, but does nmake require a fixed number of rows or so? If not, I'll just take that away before committing. Ahhh... !ERROR Make aorted. Yeah Ok, Please only it. Thanks! Regards, Hiroshi Saito ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] ecpg thread-safe descriptor
On Tue, Oct 02, 2007 at 12:23:10PM +0200, Michael Meskes wrote: On Tue, Oct 02, 2007 at 06:45:12PM +0900, ITAGAKI Takahiro wrote: Almost portability issues come from Windows, but ecpg in 8.2 only support thread-safety on pthread, not on Win32. So backporting is easier than expected because we can neglect Windows. True, but it's still a pretty huge change. I'd prefer to only backport small fixes not serious rewrites. I want thread-safe ecpg *NOW* and cannot wait for 8.3 release... Which is a valid point for backporting your changes but NOT for including them into CVS. Yeah, that's all I object to of course. Not the actual backporting. BTW, do we need to distribute ecpg with server (or client library) ? If it was a separate product, I think we will be able to maintain them more flexiblly, just like libpqxx or JDBC. I do not agree at all with this statement. IMO it's absolutely necessary that ecpg's parser is in sync with the backend's parser. So essentially we would not gain any flexibility as we'd have to release at the same time anyway. That's the reason I recall for keeping it in there as well. Michael, any chance to consider the exports-from-libecpg issue I posted about the other day? //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] ecpg thread-safe descriptor
Magnus Hagander [EMAIL PROTECTED] writes: I think this can be considered a new feature and not just a plain bugfix, so it should probably only go into HEAD. I am very nearly ready to demand that ecpg as a whole be reverted to its state as of Saturday, with all the patches since then held for 8.4 development. At no point since Sunday morning has ecpg been passing buildfarm testing, and I see no activity indicating that it's about to get fixed. You guys are holding up beta release with work that by any legitimate definition is new-feature development, and shouldn't be under consideration at all at this point. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] ecpg thread-safe descriptor
On Tue, Oct 02, 2007 at 10:39:40AM -0400, Tom Lane wrote: I am very nearly ready to demand that ecpg as a whole be reverted to its state as of Saturday, with all the patches since then held for 8.4 development. At no point since Sunday morning has ecpg been passing If we say ecpg is not multithreaded I agree that these patches are features, but if we see it as multithreaded the patches are bug fixes. buildfarm testing, and I see no activity indicating that it's about to Magnus, correct me if I'm wrong, but it appears to me that the MSVC build problem has existed for weeks or months but no one noticed so far, right? It doesn't help to revert the patches if we still do not compile cleanly on MSVC. Or is it only the DLLMAIN thing that's holding us up? If so couldn't we just remove this function and call MSVC build not multithreaded? Also Takahiro (hope this is your first name :-)), could you please explain to us why DllMain is needed at all? it isn't needed on non-Windows systems it seems. As far as fixing things you're right. We need to fix this asap. get fixed. You guys are holding up beta release with work that by any legitimate definition is new-feature development, and shouldn't be under consideration at all at this point. As I said, I considered this work bug fixes or else I wouldn't have committed the patches at this time. 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 5: don't forget to increase your free space map settings
Re: [PATCHES] ecpg thread-safe descriptor
Michael Meskes wrote: It it appears to me that the MSVC build problem has existed for weeks or months but no one noticed so far, right? This is absolutely not true. We have been building ecpg successfully on MSVC all along, just not testing. See for example the make log at http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=red_batdt=2007-09-30%20043002stg=make and search for Project: libecpg The builds only broke 2 or 3 days ago. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] initdb of regression test failed.
Hi Tom-san. initdb does not operate by the mismatch of LOCALE. - 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: could not find suitable encoding for locale Japanese_Japan.932^M Rerun initdb with the -E option.^M Try initdb --help for more information.^M Running in noclean mode. Mistakes will not be cleaned up.^M - I think this is required Did I miss something? Regards, Hiroshi Saito initdb_patch Description: Binary data ---(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.
Hiroshi Saito [EMAIL PROTECTED] writes: The database cluster will be initialized with locale Japanese_Japan.932. initdb: could not find suitable encoding for locale Japanese_Japan.932 So, what encoding *should* we use for that locale? I think this is required We are certainly not going to disable pg_regress's ability to test in non-C locales. ISTM a proper fix is an addition to the table in src/port/chklocale.c. This example suggests actually that we need a boatload more table entries to handle Windows locale names :-( (count on Microsoft to ignore standards...) regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] ecpg thread-safe descriptor
On Tue, Oct 02, 2007 at 12:53:58PM -0400, Andrew Dunstan wrote: It it appears to me that the MSVC build problem has existed for weeks or months but no one noticed so far, right? This is absolutely not true. We have been building ecpg successfully on MSVC all along, just not testing. See for example the make log at http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=red_batdt=2007-09-30%20043002stg=make and search for Project: libecpg Sorry, my bad. Seems I got this mixed up. Once we enabled testing for ecpg we had some problems to be sorted out, but right now only the DllMain thing seems to be a problem. Since I do not know whether we really need DllMain could anyone please test whether ecpg builds correctly without it? We can then sort out how to fix the problem later on. AFAIRC (and hopefully I'm right this time) multithreading never worked under msvc so we might have to set thread-safety to disabled on these systems for ecpg for the time being. 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 5: don't forget to increase your free space map settings
Re: [PATCHES] ecpg thread-safe descriptor
Michael Meskes [EMAIL PROTECTED] writes: Sorry, my bad. Seems I got this mixed up. Once we enabled testing for ecpg we had some problems to be sorted out, but right now only the DllMain thing seems to be a problem. Since I do not know whether we really need DllMain could anyone please test whether ecpg builds correctly without it? It looks to me like we should not need it, if we instead add code to initialize the mutexes properly on Windows (a la the way it's done in libpq). I can prepare a patch, but I don't have the ability to test it on Windows --- will anyone be around who can, in an hour or so? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] ecpg thread-safe descriptor
Michael Meskes wrote: On Tue, Oct 02, 2007 at 12:53:58PM -0400, Andrew Dunstan wrote: It it appears to me that the MSVC build problem has existed for weeks or months but no one noticed so far, right? This is absolutely not true. We have been building ecpg successfully on MSVC all along, just not testing. See for example the make log at http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=red_batdt=2007-09-30%20043002stg=make and search for Project: libecpg Sorry, my bad. Seems I got this mixed up. Once we enabled testing for ecpg we had some problems to be sorted out, but right now only the DllMain thing seems to be a problem. There are two problems: 1) DllMain breaks the build *completely*. This is the really urgent one. This one broke 2 days ago or so. 2) Regression tests don't pass on MSVC anymore. This broke a while ago. I was working on fixing this, but now that the build is broken there isn't much I can do until that's fixed. Since I do not know whether we really need DllMain could anyone please test whether ecpg builds correctly without it? We can then sort out how to fix the problem later on. AFAIRC (and hopefully I'm right this time) multithreading never worked under msvc so we might have to set thread-safety to disabled on these systems for ecpg for the time being. We could move the initialization somewhere else, but it needs to be somewhere. Also, see http://archives.postgresql.org/pgsql-hackers/2007-10/msg6.php for another comment on this. This changes more than just the threading stuff, but if it's something we want then this is a good time to do it. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] ecpg thread-safe descriptor
Tom Lane wrote: Michael Meskes [EMAIL PROTECTED] writes: Sorry, my bad. Seems I got this mixed up. Once we enabled testing for ecpg we had some problems to be sorted out, but right now only the DllMain thing seems to be a problem. Since I do not know whether we really need DllMain could anyone please test whether ecpg builds correctly without it? It looks to me like we should not need it, if we instead add code to initialize the mutexes properly on Windows (a la the way it's done in libpq). I can prepare a patch, but I don't have the ability to test it on Windows --- will anyone be around who can, in an hour or so? Should be doable. I can probably (but not certainly, so if someone else is around that'd be nice) get close enough to remote a windows box to test that a build passes, but remember that we can't really run the regression tests on msvc right now :-( //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] ecpg thread-safe descriptor
I wrote: Michael Meskes [EMAIL PROTECTED] writes: Since I do not know whether we really need DllMain could anyone please test whether ecpg builds correctly without it? It looks to me like we should not need it, if we instead add code to initialize the mutexes properly on Windows (a la the way it's done in libpq). Hm, I take that back --- the other reason it's there is as a kluge to avoid supporting pthread_once(). This code all looks pretty darn hokey, not to mention that it ought to be merged with libpq's pthread-win32.c, but fixing it seems not a one-hour proposition. AFAIRC (and hopefully I'm right this time) multithreading never worked under msvc so we might have to set thread-safety to disabled on these systems for ecpg for the time being. If it didn't work then this seems clearly new-feature-development. I think Magnus' idea of providing an exports list would be worth trying, if someone can try it promptly; failing that, we need to revert this patch. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Loose check was corrected of win32.mak.
Hiroshi Saito wrote: From: Magnus Hagander [EMAIL PROTECTED] + !MESSAGE nmake ended + !ERROR Make aorted. Apart from the spelling error on the second line, do we need the first line at all? It kind of says the same thing, but does nmake require a fixed number of rows or so? If not, I'll just take that away before committing. Ahhh... !ERROR Make aorted. Yeah Ok, Please only it. Thanks! Applied with fix, thanks. //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] ecpg thread-safe descriptor
On Tue, Oct 02, 2007 at 08:23:21PM +0200, Magnus Hagander wrote: test that a build passes, but remember that we can't really run the regression tests on msvc right now :-( But then we definitely need to fix this, regardless of the DllMain thing. 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 5: don't forget to increase your free space map settings
Re: [PATCHES] ecpg thread-safe descriptor
Michael Meskes wrote: On Tue, Oct 02, 2007 at 08:23:21PM +0200, Magnus Hagander wrote: test that a build passes, but remember that we can't really run the regression tests on msvc right now :-( But then we definitely need to fix this, regardless of the DllMain thing. Absolutely, but we need to fix the DllMain thing first. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] ecpg thread-safe descriptor
On Tue, Oct 02, 2007 at 02:37:40PM -0400, Tom Lane wrote: AFAIRC (and hopefully I'm right this time) multithreading never worked under msvc so we might have to set thread-safety to disabled on these systems for ecpg for the time being. If it didn't work then this seems clearly new-feature-development. Well, ecpg was said to work with multithreading but didn't. However, since the patch works on most archs if indeed fixes some bugs on those archs. I think Magnus' idea of providing an exports list would be worth trying, if someone can try it promptly; failing that, we need to revert this patch. Couldn't we just disable multithreading for Windows resp. MSVC? It appears to me that the rest of the patch is working as advertized. 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 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] ecpg thread-safe descriptor
On Tue, Oct 02, 2007 at 08:22:21PM +0200, Magnus Hagander wrote: There are two problems: 1) DllMain breaks the build *completely*. This is the really urgent one. This one broke 2 days ago or so. 2) Regression tests don't pass on MSVC anymore. This broke a while ago. I was working on fixing this, but now that the build is broken there isn't much I can do until that's fixed. When did they break? I'm still confused. Did we run regression tests at all before? Or did they never work and we just didn't notice because the buildfarm didn't run them? Also, see http://archives.postgresql.org/pgsql-hackers/2007-10/msg6.php for another comment on this. This changes more than just the threading stuff, but if it's something we want then this is a good time to do it. 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. 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 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] ecpg thread-safe descriptor
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. 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. 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
[PATCHES] minor compiler warning in libpg/fe-secure.c on win32 (msvc)
Hi, while rebuilding the entire project I ran across following warning: .\src\interfaces\libpq\fe-secure.c(593): warning C4101: 'fp' : unreferenced local variable see attached diff for a fix. -Hannes *** ../pgsql-cvshead/src/interfaces/libpq/fe-secure.c Tue Oct 2 11:43:05 2007 --- src/interfaces/libpq/fe-secure.c Tue Oct 2 23:37:48 2007 *** *** 588,596 #ifndef WIN32 struct stat buf2; #endif char fnbuf[MAXPGPATH]; - FILE *fp; BIO *bio; PGconn *conn = (PGconn *) SSL_get_app_data(ssl); char sebuf[256]; --- 588,596 #ifndef WIN32 struct stat buf2; + FILE *fp; #endif char fnbuf[MAXPGPATH]; BIO *bio; PGconn *conn = (PGconn *) SSL_get_app_data(ssl); char sebuf[256]; ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] minor compiler warning in libpg/fe-secure.c on win32 (msvc)
On Tue, 2007-10-02 at 23:45 +0200, Hannes Eder wrote: while rebuilding the entire project I ran across following warning: .\src\interfaces\libpq\fe-secure.c(593): warning C4101: 'fp' : unreferenced local variable Applied, thanks. BTW, CC'ing hackers is not necessary for trivial patches like this. -Neil ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] initdb of regression test failed.
Hi. From: Tom Lane [EMAIL PROTECTED] Hiroshi Saito [EMAIL PROTECTED] writes: The database cluster will be initialized with locale Japanese_Japan.932. initdb: could not find suitable encoding for locale Japanese_Japan.932 So, what encoding *should* we use for that locale? I think this is required We are certainly not going to disable pg_regress's ability to test in non-C locales. ISTM a proper fix is an addition to the table in src/port/chklocale.c. This example suggests actually that we need a boatload more table entries to handle Windows locale names :-( (count on Microsoft to ignore standards...) Ah Ok, Please check it. However, This problem - 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 - I think that the check of this server side is the right action.! I desire the further suggestion Regards, Hiroshi Saito chklocale_patch Description: Binary data ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[PATCHES] ecpg DllMain fix
Magnus Hagander [EMAIL PROTECTED] wrote: Absolutely, but we need to fix the DllMain thing first. 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. On another matter, this patch includes removing descriptors field in struct connection. This was my mistake in the previous fix of descriptors. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center remove-dllmain.patch Description: Binary data ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] initdb of regression test failed.
Hiroshi Saito [EMAIL PROTECTED] wrote: The database cluster will be initialized with locale Japanese_Japan.932. initdb: locale Japanese_Japan.932 requires unsupported encoding SJIS Encoding SJIS is not allowed as a server-side encoding. - I think that the check of this server side is the right action.! I desire the further suggestion How about changing initdb to use encoding=UTF-8 and no-locale when the encoding of default locale is not suppoted in the server? I think it is the most frequently used combination when we cannot use the default encoding in server. The present initdb without options always fails in such environments. Using UTF-8 with no-locale is better than error. (Error is better than using wrong locale, though.) 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.
Hi. From: ITAGAKI Takahiro [EMAIL PROTECTED] Hiroshi Saito [EMAIL PROTECTED] wrote: The database cluster will be initialized with locale Japanese_Japan.932. initdb: locale Japanese_Japan.932 requires unsupported encoding SJIS Encoding SJIS is not allowed as a server-side encoding. - I think that the check of this server side is the right action.! I desire the further suggestion How about changing initdb to use encoding=UTF-8 and no-locale when the encoding of default locale is not suppoted in the server? I think it is the most frequently used combination when we cannot use the default encoding in server. Yeah, as for Japanese, your suggestion at least is right...I think. However, how is it in other countries? I worry about it... The present initdb without options always fails in such environments. Using UTF-8 with no-locale is better than error. (Error is better than using wrong locale, though.) Is a method specified and isn't it avoided by the document, rather than ad-hoc management? Regards, Hiroshi Saito ---(end of broadcast)--- TIP 6: explain analyze is your friend
