Re: [HACKERS] [GENERAL] pg_filedump binary for CentOS

2010-10-15 Thread David Boreham
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

Re: [HACKERS] Proposed Patch - LDAPS support for servers on port 636 w/o TLS

2008-05-05 Thread David Boreham
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

Re: [HACKERS] MSVC build system

2007-08-29 Thread David Boreham
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&#

Re: [HACKERS] MSVC build system

2007-08-27 Thread David Boreham
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

Re: [HACKERS] TODO: GNU TLS

2007-01-02 Thread David Boreham
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

Re: [HACKERS] TODO: GNU TLS

2007-01-02 Thread David Boreham
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

Re: [HACKERS] TODO: GNU TLS

2007-01-02 Thread David Boreham
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.

Re: [HACKERS] TODO: GNU TLS

2007-01-02 Thread David Boreham
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

Re: [HACKERS] TODO: GNU TLS

2007-01-02 Thread David Boreham
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

Re: [HACKERS] TODO: GNU TLS

2006-12-30 Thread David Boreham
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

Re: [HACKERS] Ontology on PostgreSQL - is there something?

2006-11-18 Thread David Boreham
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

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

2006-03-06 Thread David Boreham
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

Re: [HACKERS] ice-broker scan thread

2005-11-30 Thread David Boreham
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

Re: [HACKERS] ice-broker scan thread

2005-11-30 Thread David Boreham
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

Re: [HACKERS] ice-broker scan thread

2005-11-29 Thread David Boreham
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

Re: [HACKERS] ice-broker scan thread

2005-11-29 Thread David Boreham
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

Re: [HACKERS] ice-broker scan thread

2005-11-29 Thread David Boreham
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

Re: [HACKERS] ice-broker scan thread

2005-11-28 Thread David Boreham
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

Re: [HACKERS] ice-broker scan thread

2005-11-28 Thread David Boreham
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

Re: [HACKERS] ice-broker scan thread

2005-11-28 Thread David Boreham
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

Re: [HACKERS] ice-broker scan thread

2005-11-28 Thread David Boreham
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