Jonah H. Harris wrote:
On Thu, Nov 13, 2008 at 3:20 PM, Grzegorz Jaskiewicz
<[EMAIL PROTECTED]> wrote:
If that's the situation, me thinks you guys have to start thinking about
some sort of automated way to increase this param per column as needed.
Is there any way planner could actually tell, th
Stephen Frost wrote:
> Markus,
>
> * Markus Wanner ([EMAIL PROTECTED]) wrote:
> > Stephen Frost wrote:
> > > Attached patch has this fixed and still passes all regression tests,
> > > etc.
> >
> > Do you have an up-to-date patch laying around? The current one conflicts
> > with some CVS tip chang
Ashish Kamra <[EMAIL PROTECTED]> writes:
> I was trying to call the array_in() function using the
> DirectFunctionCall3() interface. It fails as the code in array_in()
> tries to refer to fcinfo->flinfo->fnextra where flinfo is set to NULL by
> the DirectFunctionCall3() interface. I am not sure
>> In any case, saying that somebody is certifiably insane in a public
>> forum is at best questionable. I would like to see the comment
>> withdrawn.
>
> I'm not too nervous that Josh might have actually thought I thought he was
> really insane. (Or for that matter that anyone else reading it migh
So I went off to convert contrib/intagg to a wrapper around the new core
functions, along this line:
CREATE OR REPLACE FUNCTION int_agg_state (internal, int4)
RETURNS internal
AS 'array_agg_transfn'
LANGUAGE INTERNAL;
CREATE OR REPLACE FUNCTION int_agg_final_array (internal)
RETURNS int4[]
AS 'ar
It looks to me like section 34.10 of the docs might benefit from some
sort of update in light of this patch, since the builtin array_agg now
does the same thing as the proposed user-defined array_accum, only
better. Presumably we should either pick a different example, or add
a note that a builtin
Simon Riggs <[EMAIL PROTECTED]> writes:
> Your factual comments are accurate, but for Josh's stated target of Data
> Warehousing, a stats target of 400 is not unreasonable in some cases.
> What you forget to mention is that sample size is also determined by
> stats target and for large databases t
I was pretty leery about reviewing this one due to the feeling that I
might well be in over my head, but they talked me into it, so here
goes nothin'. Apologies in advance for any deficiencies in this
review.
- Overall, this looks pretty clean. The style appears to be
consistent with the surroun
I was trying to call the array_in() function using the
DirectFunctionCall3() interface. It fails as the code in array_in()
tries to refer to fcinfo->flinfo->fnextra where flinfo is set to NULL by
the DirectFunctionCall3() interface. I am not sure if this is a bug or
that we are not supposed to
> - StrategyFileStrategy doesn't handle the recently added BAS_BULKWRITE
> strategy. I'm not sure whether it needs to, but it seems to me that
> this a trap for the unwary: we should probably add a comment where the
> BAS_* constants are defined warning that any changes here may/will
> also necess
> It seems that it would be an easy evening's work to implement unnest(),
> at least in the simple form
>function unnest(anyarray) returns setof anyelement
>
> without the WITH ORDINALITY syntax proposed by the SQL spec. Then
> we could eliminate intagg's C code altogether, and just write
On Thu, 13 Nov 2008, Robert Haas wrote:
listen_addresses = '*'
This doesn't seem like a good thing to autogenerate from a security
perspective. I think we should not attempt to guess the user's
requirements in this area.
Yeah, I don't want to be the guy who flips the switch for being
On Thu, 2008-11-13 at 18:07 -0500, Greg Smith wrote:
> On Thu, 13 Nov 2008, Josh Berkus wrote:
> Since Josh's latest parameter model takes a database size as an input,
> perhaps a reasonable way to proceed here is to put the DW model into size
> tiers. Something like this:
>
> DW default_stati
On Thu, 2008-11-13 at 17:21 -0500, Greg Smith wrote:
> On Thu, 13 Nov 2008, Josh Berkus wrote:
> > BTW, I think this is still in enough flux that we really ought to make
> > it a pgfoundry project. I don't think we'll have anything ready for 8.4
> > contrib.
>
> I find your lack of faith distu
Tom Lane wrote:
> The original reason for doing this work, I think, was to let us
> deprecate contrib/intagg, or at least turn it into a thin wrapper
> around core-provided functionality. We now have the means to do that
> for int_array_aggregate, but what about int_array_enum?
And what about th
Josh Berkus wrote:
> Thanks for defending me. I think Greg threw that at me because he knows
> I'm very difficult to offend, though. I assume that Greg wouldn't make a
> post like that to other members of the community.
I would print it and frame it to hang somewhere in the office ... or
may
Tom Lane wrote:
> Still, I agree that the whole thing looks too Rube Goldbergian to count
> as a reliability enhancer, which is what the point is after all.
Agreed.
> I think the argument is about whether we increase our vulnerability to
> torn-page problems if we just add a CRC and don't do any
Markus,
* Markus Wanner ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
> > Attached patch has this fixed and still passes all regression tests,
> > etc.
>
> Do you have an up-to-date patch laying around? The current one conflicts
> with some CVS tip changes.
No, not yet. I suspect the array_
On 2008-11-08 09:25, Benedek László wrote:
Does this work if the role name contains a ' ?
Right, this one fails with ' in the role name. An update coming soon
closing this issue.
Here is an updated patch, which deals with 's in the rolename.
Please review.
doc/src/sgml/ref/pg_dump.sgml
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Jeff Davis wrote:
>> Here's an updated patch for just array_accum() with some simple docs.
> I have committed a "best of Robert Haas and Jeff Davis" array_agg()
> function with standard SQL semantics. I believe this gives the best
> consistency wit
>listen_addresses = '*'
This doesn't seem like a good thing to autogenerate from a security
perspective. I think we should not attempt to guess the user's
requirements in this area.
>max_fsm_pages = DBsize / PageSize / 8
Isn't this moot for 8.4?
...Robert
--
Sent via pgsql-ha
On Thu, 13 Nov 2008, Josh Berkus wrote:
Even though we all agree default_statistics_target = 10 is too low,
proposing a 40X increase in the default value requires more evidence
than this. In particular, the prospect of a 1600-fold increase in
the typical cost of eqjoinsel() is a mite scary.
I
Simon,
In any case, saying that somebody is certifiably insane in a public
forum is at best questionable. I would like to see the comment
withdrawn.
Thanks for defending me. I think Greg threw that at me because he knows
I'm very difficult to offend, though. I assume that Greg wouldn't make
Tom,
Even though we all agree default_statistics_target = 10 is too low,
proposing a 40X increase in the default value requires more evidence
than this. In particular, the prospect of a 1600-fold increase in
the typical cost of eqjoinsel() is a mite scary.
It's a *completely* acceptable trade
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> Actually, the real problem to me seems to be that to check the checksum
> when you read the page in, you need to look at the contents of the page
> and "assume" some of the values in there are correct, before you can
> even calculate the checksum
On Thu, 2008-11-13 at 20:33 +0100, Greg Stark wrote:
> A statistic target of 400 fir a specific column may make sense but
> even then I would recommend monitoring performance to ensure it
> doesn't cause problems. As a global setting it's, IMHO, ridiculous.
>
> Even for the smaller data type
On Thu, 13 Nov 2008, Josh Berkus wrote:
don't bother with os.sysconf, or make it optional and error-trap it.
Right, I've moved in that direction in the updated rev I already
sent--memory is an input value, but if you leave it out it tries to guess.
Just need a bit more error trapping around
On Thu, Nov 13, 2008 at 01:45:52PM -0500, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I'm still testing this; please beware that this likely has an even
> > higher bug density than my regular patches (and some debugging printouts
> > as well).
>
> This seems impossibly fragile
On Thu, 2008-11-13 at 14:31 -0500, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > Thanks! This patch is ready to go, as far as I'm concerned.
>
> This patch seems to contain a subset of the "contrib infrastructure"
> patch that's listed separately on the commitfest page. While I hav
>> - "make check" fails 16 of 118 tests for me with this patch applied.
> Most of them are caused by additional NOTICE messages or unexpected
> additional rules in the rewriter regression tests. I don't see anything
> critical here.
Possible; in that case you should patch the expected regression o
* Tom Lane <[EMAIL PROTECTED]> [081113 14:43]:
> Well, if we adopt the double buffering approach then the ex-lock would
> only need to be held for long enough to copy the page contents to local
> memory. So maybe this would be acceptable. It would certainly be a
> heck of a lot simpler than any
On Thu, Nov 13, 2008 at 3:20 PM, Grzegorz Jaskiewicz
<[EMAIL PROTECTED]> wrote:
> If that's the situation, me thinks you guys have to start thinking about
> some sort of automated way to increase this param per column as needed.
> Is there any way planner could actually tell, that it would do bette
On Thu, Nov 13, 2008 at 03:10:04PM -0500, Tom Lane wrote:
> clean distclean:
> ! rm -f keywords.c *.o ecpg$(X) preproc.y
>
> Actually, we want to fix it so that preproc.y is treated like preproc.c,
> ie, it's part of the shipped tarballs even though it's no longer in CVS.
That's what I did
Michael Meskes <[EMAIL PROTECTED]> writes:
> That's what I did first, but Magnus had a good reasoning to not keep preproc.y
> if we keep preproc.c in our tarball. And I agreed that there doesn't seem to
> be
> an advantage.
Other than whether it *works*, you mean?
make will not be happy if it ha
Andrew Chernow <[EMAIL PROTECTED]> writes:
>> Here are the options we see:
>>
>> 1. PQregisterEventProc returns a handle, synchronized counter
>> incremented by libpq. A small table could map handle value to proc
>> address, so register always returns the same handle for a provided
>> eventpro
On 2008-11-13, at 19:33, Greg Stark wrote:
A statistic target of 400 fir a specific column may make sense but
even then I would recommend monitoring performance to ensure it
doesn't cause problems. As a global setting it's, IMHO, ridiculous.
If that's the situation, me thinks you guys ha
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Another idea would be to take a large sample in ANALYZE, but if the
> distribution looks "regular enough", store less samples in the
> Most-Common-Values list and fewer histograms, to make the planning faster.
Yeah, some flexibility at that end mi
Michael Meskes <[EMAIL PROTECTED]> writes:
> since my last email seems to have disappeared, here we go again. Here's my
> current patch that includes the changes to the build system. Thanks to Magnus
> for the Windows part.
> Comments anyone?
+ $(srcdir)/preproc.y: $(top_srcdir)/src/backend/pars
Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
>> XFS, for example, zeroes out during recovery any block
>> that was written to but not fsync'ed before a crash. This means that if
>> we change a hint bit after a checkpoing and mark the page dirty, the
>> system can write the page. Suppose we c
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
A lot of people have suggested raising our default_statistics target,
and it has been rejected because there's some O(n^2) behavior in the
planner, and it makes ANALYZE slower, but it's not that crazy.
I think everyone agrees it o
Hi,
since my last email seems to have disappeared, here we go again. Here's my
current patch that includes the changes to the build system. Thanks to Magnus
for the Windows part.
Comments anyone?
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Mi
Alvaro Herrera wrote:
XFS, for example, zeroes out during recovery any block
that was written to but not fsync'ed before a crash. This means that if
we change a hint bit after a checkpoing and mark the page dirty, the
system can write the page. Suppose we crash at this point. On
recovery, XFS
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> A lot of people have suggested raising our default_statistics target,
> and it has been rejected because there's some O(n^2) behavior in the
> planner, and it makes ANALYZE slower, but it's not that crazy.
I think everyone agrees it ought to be ra
Alvaro Herrera wrote:
> Tom Lane wrote:
>
> > Basically, you can't make any critical changes to a shared buffer
> > if you haven't got exclusive lock on it. But that's exactly what
> > this patch is assuming it can do.
>
> It seems to me that the only possible way to close this hole is to
> acqu
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Basically, you can't make any critical changes to a shared buffer
>> if you haven't got exclusive lock on it. But that's exactly what
>> this patch is assuming it can do.
> It seems to me that the only possible way to close this hole
Gregory Stark wrote:
Josh Berkus <[EMAIL PROTECTED]> writes:
DW:
default_statistics_target = 400
Mixed:
default_statistics_target = 100
You, my friend, are certifiably insane.
I almost fell off the chair because of that comment, but after I stopped
laughing and actually loo
A statistic target of 400 fir a specific column may make sense but
even then I would recommend monitoring performance to ensure it
doesn't cause problems. As a global setting it's, IMHO, ridiculous.
Even for the smaller data types (except boolean and "char") and array
of 400 will be large e
Jeff Davis <[EMAIL PROTECTED]> writes:
> Thanks! This patch is ready to go, as far as I'm concerned.
This patch seems to contain a subset of the "contrib infrastructure"
patch that's listed separately on the commitfest page. While I have
no strong objection to what's here, I'm wondering what sort
Aidan Van Dyk wrote:
>
> I think I'm missing something...
>
> In this patch, I see you writing WAL records for hint-bits (bufmgr.c
> FlushBuffer). But doesn't XLogInsert then make a "backup block" record
> (unless
> it's already got one since last checkpoint)?
I'm not causing a backup block to
Tom Lane wrote:
> Basically, you can't make any critical changes to a shared buffer
> if you haven't got exclusive lock on it. But that's exactly what
> this patch is assuming it can do.
It seems to me that the only possible way to close this hole is to
acquire an exclusive lock before calling F
I think I'm missing something...
In this patch, I see you writing WAL records for hint-bits (bufmgr.c
FlushBuffer). But doesn't XLogInsert then make a "backup block" record (unless
it's already got one since last checkpoint)?
Once there's a backup block record, the torn-page problem that causes
Josh Berkus <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> Josh Berkus <[EMAIL PROTECTED]> writes:
>>> DW:
>>> default_statistics_target = 400
>>> Mixed:
>>> default_statistics_target = 100
>>
>> You, my friend, are certifiably insane.
> Hmmm? Why? I've used those settings in the field,
Tom Lane wrote:
And it's not even
clear to me that it fixes the problem: wouldn't you get two different
handles if you supplied the internal and external addresses of an
eventproc?
Both #1 and #4 suffer from this issue, internal & external register
methods. They also require the same WARNIN
Josh,
Actually that is a poorly worded page. It really should be something
like, "How to submit a patch" or "How to get your patch committed".
Yeah, I told Bruce I was going to re-write that page but seem to have
been short some Round Tuits.
--Josh
--
Sent via pgsql-hackers mailing list (
Decibel! <[EMAIL PROTECTED]> writes:
> That seems like a deal-breaker to me... many users could easily be
> depending on views not being updateable. Views are generally always
> thought of as read-only, so you should need to explicitly mark a view
> as being updateable/insertable/deleteable.
Greg,
BTW, I think this is still in enough flux that we really ought to make
it a pgfoundry project. I don't think we'll have anything ready for 8.4
contrib.
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgre
On Nov 11, 2008, at 10:06 PM, Robert Haas wrote:
- Should this be an optional behavior? What if I don't WANT my view
to be updateable?
That seems like a deal-breaker to me... many users could easily be
depending on views not being updateable. Views are generally always
thought of as read-
Gregory Stark wrote:
Josh Berkus <[EMAIL PROTECTED]> writes:
DW:
default_statistics_target = 400
Mixed:
default_statistics_target = 100
You, my friend, are certifiably insane.
Hmmm? Why? I've used those settings in the field, fairly frequently.
I was actually wondering if
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I'm still testing this; please beware that this likely has an even
> higher bug density than my regular patches (and some debugging printouts
> as well).
This seems impossibly fragile ... and the non-modular assumptions about
what is in a disk page aren
Josh Berkus <[EMAIL PROTECTED]> writes:
> DW:
> default_statistics_target = 400
> Mixed:
> default_statistics_target = 100
You, my friend, are certifiably insane.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres supp
"Dmitry Koterov" <[EMAIL PROTECTED]> writes:
> 3. The function a() calls any OTHER function b() from OTHER namespace (or
> uses operators from other namespaces), but does not specify the schema name,
> because it is in database search_path:
> CREATE FUNCTION a(i integer) RETURNS boolean AS $$
> B
Greg,
Attached version takes all its input via command line switches. If you
don't specify an explict number of connections, it also implements
setting max_connections via some of the logic from your calcfactors
spreadsheet.
OK, I'll review. What follows is a review of the *previous* versi
Gregory Stark wrote:
> I think we're talking past each other. Martin and I are talking about doing
> something like:
>
> for (...)
> ...
> crc(word including hint bits)
> ...
> for (each line pointer)
> crc-negated(word & LP_DEAD<<15)
>
> Because CRC is a cyclic checksum it's possible t
Magnus Hagander <[EMAIL PROTECTED]> writes:
> I am unsure of exactly where this thing hacks into the authentication
> stream, but is it really only MD5 that fails?
The problem with md5 is that the username is part of the encryption salt
for the stored password, so changing it breaks that --- the c
Per bug #4528, I'm thinking we should do $SUBJECT. I'm inclined to
put a tz_acceptable() check into pg_tzenumerate_next, which is currently
only used by that view but might be used for other purposes later.
Any objections?
regards, tom lane
--
Sent via pgsql-hackers mai
I did this:
http://archives.postgresql.org/pgsql-committers/2008-11/msg00156.php
to try to fix this:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=narwhal&dt=2008-11-12%2021:00:01
only to get this:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=narwhal&dt=2008-11-13%2015:00:01
Anybody know
Jeff Davis wrote:
Here's an updated patch for just array_accum() with some simple docs.
I have committed a "best of Robert Haas and Jeff Davis" array_agg()
function with standard SQL semantics. I believe this gives the best
consistency with other aggregate functions for the no-input-rows cas
On Wed, Nov 12, 2008 at 02:28:56PM -0800, Ron Mayer wrote:
> Merging of the interval style into ecpg attached.
Thanks for caring about the ecpg changes too.
> I know little enough about ecpg that I can't really tell if these changes
> are for the better or worse.
The closer pgtypeslib is to the
Hello.
Why pg_dump dumps CONSTRAINT ... CHECK together with CREATE TABLE queries,
but NOT at the end of dump file (as FOREIGN KEY)?
Sometimes it causes the generation of invalid dumps which cannot be
restored. Details follow.
1. I use database-dedicated search_path:
ALTER DATABASE d SET search_
Hi,
Who is in charge of pg_filedump now?
I noticed that the latest version (for 8.3) does not play nice with
HEAD, because of changes in ControlFileData. The attached patch fixes
that, allowing it to compile.
I didn't look if there were other changes needed for it to actually
work; any clues?
--On Dienstag, November 11, 2008 23:06:08 -0500 Robert Haas
<[EMAIL PROTECTED]> wrote:
Thanks for your look at this. Unfortunately i was travelling the last 2
days, so i didn't have time to reply earlier, sorry for that.
I haven't done a full review of this patch, but here are some thoughts
Andrew Chernow wrote:
Tom Lane wrote:
Andrew Chernow <[EMAIL PROTECTED]> writes:
Just noticed that the last libpqtypes release was broken on windows
when dynamically linking. The problem is that windows has two
addresses for functions, the import library uses a stub "ordinal"
address while t
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Who is in charge of pg_filedump now?
It's usually me that fixes it for new PG versions. I don't normally
try to track CVS HEAD, just update it at release time.
> I noticed that the latest version (for 8.3) does not play nice with
> HEAD, because of ch
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> I am unsure of exactly where this thing hacks into the authentication
>> stream, but is it really only MD5 that fails?
>
> The problem with md5 is that the username is part of the encryption salt
> for the stored password, so changin
Bruce Momjian wrote:
> Magnus Hagander wrote:
>>> I have developed the attached patch, which documents the inability to
>>> use MD5 with db_user_namespace, and throws an error when it is used:
>>>
>>> psql: FATAL: MD5 authentication is not supported when
>>> "db_user_namespace" is enabled
>>
Hi, Pgsql-hackers.
> many seem (to me) to be overly tied to an "all XML all the time" view.
Only for hierarchical result sets. Even in case of
http://computer20.euro.ru/site/computer20/en/author/communication_eng.htm
Dmitry (SQL50, HTML60)
--
Sent via pgsql-hackers mailing list (pgsql-hack
Hello Stephen,
Stephen Frost wrote:
> Attached patch has this fixed and still passes all regression tests,
> etc.
Do you have an up-to-date patch laying around? The current one conflicts
with some CVS tip changes.
I didn't get around writing some docu, yet. Sorry.
Regards
Markus Wanner
--
S
Bruce Momjian wrote:
> Yes, my defines were very messed up; updated version attached.
>
Hi,
I've not done a review of this patch, however I did backport it to 8.3
(as attached in unified diff). The patch wasn't made for PG purposes, so
it's not in context diff. I tested the backported patch an
Charlie Savage wrote:
> Just wanted to close off this thread.
>
> Previously I reported that building 8.3.4 with MingW on Windows resulted
> in an initdb executable that couldn't create new databases due to
> security restrictions in creating global file mappings in Vista.
>
> I'm happy to say th
Attached patch implements client certificate authentication.
I kept this sitting in my tree without sending it in before the
commitfest because it is entirely dependent on the
not-yet-reviewed-and-applied patch for how to configure client
certificate requesting. But now that I learned how to do it
Hi,
Hannu Krosing wrote:
>> As I know, you can use show mutex status in MySQL to find which mutex
>> is hot. But i don't know in PostgreSQL.
>
> look at pg_locks system view
Or read about dtrace to analyze lower level locking contention:
http://www.postgresql.org/docs/8.3/static/dynamic-trace.h
On Thu, 2008-11-13 at 18:55 +0800, [EMAIL PROTECTED] wrote:
> Hi all:
>
> I am a fresh men in PostgreSQL. And i work on benchmark study
> these days using PostgreSQL.
>
> Now i have a question: Is there some way to show the lock contention
> of PostgreSQL?
>
> As I know, you can use show m
--- On Wed, 12/11/08, Tony Fernandez <[EMAIL PROTECTED]> wrote:
> Date: Wednesday, 12 November, 2008, 10:52 PM
> Hello lists,
>
>
>
> I am trying to run Slony on a Master Postgres 8.1.11
> replicating to a
> Slave same version and 2nd Slave Postgres 8.3.4.
>
> I am getting the following err
Hi all:
I am a fresh men in PostgreSQL. And i work on benchmark study these
days using PostgreSQL.
Now i have a question: Is there some way to show the lock contention of
PostgreSQL?
As I know, you can use *show mutex status* in MySQL to find which mutex is
hot. But i don't know in
Postg
2008/11/5 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> 2008/11/4 Tom Lane <[EMAIL PROTECTED]>:
>>> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
a) server crash after creating tsearch2 function (I use tsearch2
contrib from 8.3)
>>>
>>> I couldn't reproduce
I am sending patch, that adds FOUND and GET DIAGNOSTICS support for
RETURN QUERY statement
Regards
Pavel Stehule
2008/11/10 Andrew Gierth <[EMAIL PROTECTED]>:
>> "Pavel" == "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>
> >> Well, changing the semantics of an already-released statement
> >
It means I will go ahead and apply it once I have looked it over once
more.
Thanks for review+testing!
You may now move on to the next ssl patch if you're interested ;)
/Magnus
On 12 nov 2008, at 17.05, "Alex Hunsaker" <[EMAIL PROTECTED]> wrote:
OK now that im using the right env var eve
87 matches
Mail list logo
