On 10/15/2010 7:24 AM, Robert Haas wrote:
I think that's a bad idea for all kinds of reasons. For one thing, it
seems that someone could easily end up copying some of that code into
some other place. It would be *nice* to have this available as part
of our regular distribution but I don't want
Andreas Pflug wrote:
With ldaps on port 636 STARTTLS should NEVER be issued, so the
protocol identifier ldaps should be sufficient as "do not issue
STARTTLS" flag. IMHO the current pg_hba.conf implementation doesn't
follow the usual nomenclatura; ldap with TLS is still ldap. Using
ldaps as ind
Magnus Hagander wrote:
David Boreham wrote:
To add my 2d worth to this: after working on a few very large
projects that built on both Unix and Windows my preference is
to use a single autotools-based build for both, with a script called cccl
that translates cc-style arguments for Microsoft
Neil Conway wrote:
On Mon, 2007-08-27 at 11:00 -0400, Andrew Dunstan wrote:
In the longer run I want to make the whole system more data driven, so
that it's comparatively easy for someone to add stuff.
I don't mean to hijack your thread, but I wonder if maintaining two
separate build s
Martijn van Oosterhout wrote:
- Thread safety (GnuTLS is thread-safe by design, no locks needed)
- Proper layering (creating your own I/O function is trivial)
- Seperate namespace
- Non-blocking support from the get-go
were taken care of. Since people are citing maintainability as a
concern, I
Stephen Frost wrote:
Also, do we really want to import the NSPR into Postgres? I suspect not.
Of course, the only thing that people are tripping over license-wise is
libpq. But I think we would want to keep that as lean and mean as
possible, too.
erm, I'm not really sure what you're say
Andrew Dunstan wrote:
I suspect most postgres developers and companies would like to keep
things as BSDish as possible.
Right, hence OpenSSL would be the obvious best choice.
In respect of licencing however, NSS is no 'worse' than GNU TLS
because it may be distributed under the GPL and LGPL.
Stephen Frost wrote:
* David Boreham ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
Not sure what license that's under,
From http://www.mozilla.org/projects/security/pki/nss/:
'NSS is available under the Mozilla Public License, the GNU General
Public License, a
Stephen Frost wrote:
* David Boreham ([EMAIL PROTECTED]) wrote:
Fascinating thread for the holidays. I found it interesting that nobody
has mentioned
NSS (former Netscape SSL library). It has its own bag of problems of
course, but
for me is potentially more attractive than GNU TLS. e.g. it
Tom Lane wrote:
What basically bothers me about this is that trying to support both the
OpenSSL and GNUTLS APIs is going to be an enormous investment of
development and maintenance effort, because it's such a nontrivial thing
Fascinating thread for the holidays. I found it interesting that no
Josh Berkus wrote:
That I don't understand what they're talking about. What's "Ontology" in a
database sense? Can you give some examples?
You'll need to RTFP , which in all fairness the OP did cite in his posting :
http://www.cs.toronto.edu/vldb04/protected/eProceedings/contents/pdf/I
OTOH neither JBoss, BerkeleyDB, Qt are listed. Is there a pattern here?
http://www.coverity.com/news/news_02_15_05_story_6.html
---(end of broadcast)---
TIP 6: explain analyze is your friend
Qingqing Zhou wrote:
[also with reply to Gavin] look up dictionary for "gut-rot", got it ... Uh,
this behavior is intended - I try to push enough requests shortly to kernel
so that it understands that I am doing sequential scan, so it would pull the
data from disk to file system cache more eff
Yes. The O_DIRECT issue is my biggest concern about Linux at the moment.
That being said, the plan is to only pre-fetch the next N blocks, where N
< 32, and to read them into the local buffer cache. In a situation where
space in the cache low (and prefetched pages might be pushed out before we
e
By default when you use aio you get the version in libc (-lrt IIRC)
which has the issue I mentioned, probably because it's probably
optimised for the lots-of-network-connections type program where
multiple outstanding requests on a single fd are not meaningful. You
can however link in some other
Unfortunatly I can't really test it at it's full potential because it
uses glibc's default POSIX AIO which is *lame*. No more than one
outstanding request per fd which for PostgreSQL is crappy. There was
I had the impression from the kernel aio mailing list a while back that
post- linux, the
threw up some threads to read ahead, then my user thread and my read
ahead threads would thrash on trying to lock the buffer slots. So, I
had the read ahead threads start at some distance into the table, and
work toward the beginning. The user thread would do its own I/O until
Ah. The ligh
Qingqing Zhou wrote:
On Mon, 28 Nov 2005, Gavin Sherry wrote:
MySQL, Oracle and others implement read-ahead threads to simulate async IO
'pre-fetching'.
Due to my tests on Windows (using the attached program and change
enable_aio=true), seems aio doesn't help as a separ
The paper I linked to seemed to suggest that they weren't using async IO
in 9.2 -- which is fairly old. I'm not sure why the authors didn't test
10g.
.. ok, interesting. Did they say that Oracle
isn't using aio ?
I can't see that. They that Oracle has no more than one outstanding I
Gavin Sherry wrote:
MySQL, Oracle and others implement read-ahead threads to simulate async IO
I always believed that Oracle used async file I/O. Not that I've seen their
code, but I'm fairly sure they funded the addition of kernel aio to Linux
a few years back.
ButOracle comes from a tim
Qingqing Zhou wrote:
I am considering add an "ice-broker scan thread" to accelerate PostgreSQL
sequential scan IO speed. The basic idea of this thread is just like the
"read-ahead" method, but the difference is this one does not read the data
into shared buffer pool directly, instead, it reads t
21 matches
Mail list logo