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.
-
"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 i
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
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
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
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/inte
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
>> resu
Michael Meskes wrote:
> 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 whil
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 fi
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 n
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 w
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 Fa
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 ro
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 l
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 DllMai
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
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
>
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
"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
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 w
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.pgbu
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 mul
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 f
On Tue, Oct 02, 2007 at 12:31:37PM +0200, Magnus Hagander wrote:
> > 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.
This is how I understood your email anyway. :-)
> Michael, an
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 be
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
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
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:
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 porta
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,
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 becau
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
32 matches
Mail list logo
