> -Original Message-
> From: Tom Lane
> Did you try running the regression tests under tr_TR locale? It seems
> a few bricks short of "fine" yet :-(
I run regression tests under tr_TR locale. To do this I hardcoded
Turkish locale in initdb in pg_regress.sh. Three tests failed, I
attached
Ok, so it's something specific to my setup. I created a test account,
logged in and compiled postgresql there with a clean shell environment
and it worked fine. So I'm shooting myself in the foot in my login
environment. *sigh*.
thanks,
/s.
On Feb 21, 2004, at 1:51 AM, Tom Lane wrote:
Scott
Thomas Hallgren wrote:
That's an interesting thougth. The postmaster just forks. It never exec's
right? Is this true for win32 as well? I've never tried it but it might be
worth pursuing. Sun's new Java 1.5 jvm does this albeit a bit differently.
An initializer process starts up and persists its st
Thomas Hallgren wrote:
Other than that fear, though, the JNI approach seems to have pretty
considerable advantages. You listed startup time as the main
disadvantage, but perhaps that could be worked around. Suppose the
postmaster started a JVM --- would that state inherit correctly into
subseq
Hackers,
FYI here are some of my thoughts I just sent to Joshua Drake.
I would add a couple of points:
. since there is a security advisory for Safe.pm prior to version 2.08,
maybe we should replace "require Safe;" with "use Safe 2.08;".
. I thought about some sort of precompilation methods for
> It's been considered and rejected before, and pljava isn't going to tilt
> the scales.
>
Didn't think it would. Thought it worth mentioning anyway, partly to get
your reaction.
> In fact, the main thing that bothers me about your
> description of JNI is "Java uses multithreading wether you like
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Could I suggest that your next step is to sync up with the work being
> done on tuning the DBT-3 query workload? As I'm sure you're aware, that
> is very similar to TPC-H workload, where most of the commercial RDBMS
> vendors utilise Materialized Views to
"Thomas Hallgren" <[EMAIL PROTECTED]> writes:
> ** 4. Make the postmaster spawn threads rather than processes **
> I know this is very controversial and perhaps I should not bring it up at
> all. But then again, why not? Most readers are open-minded right?
It's been considered and rejected before,
"Nicolai Tufar" <[EMAIL PROTECTED]> writes:
>> It looks to me like every use of strcasecmp in the backend has to be
>> questioned if we're going to make this work. I'm starting to lean in
>> the direction of "tr_TR is hopelessly broken" again...
> With this patch applied everything works fine. Th
>Jonathan M. Gardner
> I've implemented a pretty simple Materialized Views scheme. It's not
> terribly complicated, and it works quite well.
Exciting news - excellent work. Starting simple was the right approach!
> There were some issues with the time-sensitivity of the queries. For
> instance, o
Two Pl/Java implementations exists today. Due to the architecture of
PostgreSQL, compromises have been made in both of them to deal with the fact
that each connection lives in its own process. One, I'll call it
"Pl/Java_JNI" will spawn a JVM on demand for each connection and the other,
"Pl/Java_rem
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Hmm. It seems that tr_TR has problems much more extensive than you've
> indicated previously. I was able to get through initdb with the
attached
> additional patch, but the regression tests fail in several places.
> It look
12 matches
Mail list logo
