Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Mike Mascari
- Original Message - From: Bruce Momjian [EMAIL PROTECTED] Tom said that our low-hanging fruit is gone and only hard items are left. This is certainly true. What is hard to accept is that those big items take _weeks_ of focused development, and we just don't have enough full-time

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Andreas Pflug
Tom Lane wrote: I spent weeks doing hash aggregates, weeks doing IN-subselect optimization, and am in the middle of many weeks on FE/BE protocol improvement. I am sorry that you don't see these as killer features ... but they are all things that we desperately needed to do. For me, the 7.4

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Bruce Momjian
Mike Mascari wrote: I was disappointed that Satoshi Nagayasu's two-phase commit patches seemed to be implicitly rejected by lack of an enthusiastic response by any of the core members. Distributed query (not replication) would have been a very nice feature. It's what separates, in part,

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Jan Wieck
Tom Lane wrote: BTW, I would not approve of a response along the lines of can't you #ifdef to the point that there are no code changes in the Unix builds? No you can't, unless you want to end up with an unmaintainable mess of #ifdef spaghetti. The thing that makes this hard is the tradeoff

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Jan Wieck
Dann Corbit wrote: PostgreSQL's regression tests (IMHO) are much better than MySQL's crash-me scripts. They are less thorough in coverage, but not too bad. Right, we are still missing this test that proves 10,000 CREATE+DROP TABLE will ensure that PostgreSQL is slower than MySQL, if you don't

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Jan Wieck
Dann Corbit wrote: -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Are you volunteering to create it? Step right up. No. And as an outsider, I rather doubt if any procedures I developed would be taken very seriously. If such procedures are to be developed, I suspect that

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Jan Wieck
Alvaro Herrera wrote: Also they don't test things they don't support. Is there a test for subselects? What about concurrency? Transactional issues? What about performance when they have their transaction support enabled? Sure don't they. Like their NUMERIC data type, that can *store* any

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Rod Taylor
On Sun, 2003-06-22 at 07:44, Bruce Momjian wrote: Mike Mascari wrote: I was disappointed that Satoshi Nagayasu's two-phase commit patches seemed to be implicitly rejected by lack of an enthusiastic response by any of the core members. Distributed They weren't ready to be committed at the

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Bruce Momjian
Jan Wieck wrote: Tom Lane wrote: BTW, I would not approve of a response along the lines of can't you #ifdef to the point that there are no code changes in the Unix builds? No you can't, unless you want to end up with an unmaintainable mess of #ifdef spaghetti. The thing that makes this

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread The Hermit Hacker
On Sun, 22 Jun 2003, Bruce Momjian wrote: Mike Mascari wrote: I was disappointed that Satoshi Nagayasu's two-phase commit patches seemed to be implicitly rejected by lack of an enthusiastic response by any of the core members. Distributed query (not replication) would have been a very

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread The Hermit Hacker
On Sat, 21 Jun 2003, Bruce Momjian wrote: That's a tough call. I do worry about readability. We have made Win32 changes, and they aren't ifdefs, and we still have a running system, and I think we can do that for PITR too. I think the big issue, which may be your point, is to get incremental

Re: [HACKERS] O_DIRECT in freebsd

2003-06-22 Thread Sean Chittenden
The reason I mention it is that Postgres already supports O_DIRECT I think on some other platforms (for whatever reason). [ sounds of grepping... ] No. The only occurrence of O_DIRECT in the source tree is in TODO: * Consider use of open/fcntl(O_DIRECT) to minimize

Re: [HACKERS] compile failure on cvs tip --with-krb5

2003-06-22 Thread Sean Chittenden
This change (I'm sure this will wrap poorly -- sorry): http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/include/libpq/pqcomm.h.diff?r1=1.85r2=1.86 modified SockAddr, but no corresponding change was made here (fe-auth.c:612): case AUTH_REQ_KRB5: #ifdef KRB5 if

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread The Hermit Hacker
On Fri, 20 Jun 2003, Dann Corbit wrote: Designing tests is busywork. Desiging tests is boring. Nobody wants to design tests, let alone interpret the results and define correct baselines. But testing is very, very important. But we do do testing ... we even design testing (in the form of

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread The Hermit Hacker
On Sat, 21 Jun 2003, Dann Corbit wrote: It seems pretty clear that there are warts on the Crashme test. Perhaps 70% or so is truly useful. Maybe the useful subset could be approximated or modified to be useful as a general tool set. And we all wait with baited breath for you to develop and

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Mike Mascari
The Hermit Hacker wrote: On Sun, 22 Jun 2003, Bruce Momjian wrote: Mike Mascari wrote: I was disappointed that Satoshi Nagayasu's two-phase commit patches seemed to be implicitly rejected by lack of an enthusiastic response by any of the core members. Distributed query (not replication) would

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Jan Wieck
The Hermit Hacker wrote: On Fri, 20 Jun 2003, Dann Corbit wrote: Designing tests is busywork. Desiging tests is boring. Nobody wants to design tests, let alone interpret the results and define correct baselines. But testing is very, very important. But we do do testing ... we even design

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread The Hermit Hacker
On Sun, 22 Jun 2003, Jan Wieck wrote: The Hermit Hacker wrote: On Fri, 20 Jun 2003, Dann Corbit wrote: Designing tests is busywork. Desiging tests is boring. Nobody wants to design tests, let alone interpret the results and define correct baselines. But testing is very, very

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Peter Eisentraut
Bruce Momjian writes: I have added a cleaned up version of this to CVS as src/tools/pgtest. This seems to be a platform-specific reimplementation of 'make clean; make check'. Why bother? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of

Re: [HACKERS] Access to transaction status

2003-06-22 Thread Christian Plattner
- Original Message - From: Jeroen T. Vermeulen [EMAIL PROTECTED] I ran into the same need (Bruce, we discussed this at FOSDEM in Brussels this February) for libpqxx. My code tries to compensate for the possibility that the backend connection is lost while waiting for a reply to a

Re: tsearch V2 (Was: Re: [HACKERS] Two weeks to feature freeze)

2003-06-22 Thread Bruce Momjian
The Hermit Hacker wrote: And, actually, for some reason I hadn't thought of the tsearch as being another 'INDEX' type ... I crawl back over and be quiet now :) Oleg, as far as commits are concerned, I have no problems with extending the privileges to one of your guys for this, just email

Re: [HACKERS] interval's and printing...

2003-06-22 Thread Bruce Momjian
Tom Lane wrote: Larry Rosenman [EMAIL PROTECTED] writes: Why does the interval type not print seconds when they are zero? Seems like a bug to me too. Anyone think it's not? Note this only occurs with DateStyle = ISO, the other datestyles use a different format for intervals. Clearly

Re: [HACKERS] O_DIRECT in freebsd

2003-06-22 Thread Bruce Momjian
What you really want is Solaris's free-behind, where it detects if a scan is exceeding a certain percentage of the OS cache and moves the pages to the _front_ of the to-be-reused list. I am not sure what other OS's support this, but we need this on our own buffer manager code as well. Our TODO

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Bruce Momjian
Peter Eisentraut wrote: Bruce Momjian writes: I have added a cleaned up version of this to CVS as src/tools/pgtest. This seems to be a platform-specific reimplementation of 'make clean; make check'. Why bother? Marc requested it. Is there anything platform-specific except the greps?

Re: [HACKERS] O_DIRECT in freebsd

2003-06-22 Thread Sean Chittenden
What you really want is Solaris's free-behind, where it detects if a scan is exceeding a certain percentage of the OS cache and moves the pages to the _front_ of the to-be-reused list. I am not sure what other OS's support this, but we need this on our own buffer manager code as well. Our

Re: [HACKERS] O_DIRECT in freebsd

2003-06-22 Thread Bruce Momjian
Sean Chittenden wrote: What you really want is Solaris's free-behind, where it detects if a scan is exceeding a certain percentage of the OS cache and moves the pages to the _front_ of the to-be-reused list. I am not sure what other OS's support this, but we need this on our own buffer

Re: [HACKERS] O_DIRECT in freebsd

2003-06-22 Thread Sean Chittenden
What you really want is Solaris's free-behind, where it detects if a scan is exceeding a certain percentage of the OS cache and moves the pages to the _front_ of the to-be-reused list. I am not sure what other OS's support this, but we need this on our own buffer manager code as

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Sailesh Krishnamurthy
Let me add my two cents .. I think something like PostgreSQL needs two test suites - an acceptance test (to ensure that checkins don't break functionality) and a regression test suite. What we call the regression test suite is really an acceptance test. Tom Lane is absolutely right in asserting

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread The Hermit Hacker
On Sun, 22 Jun 2003, Bruce Momjian wrote: Peter Eisentraut wrote: Bruce Momjian writes: I have added a cleaned up version of this to CVS as src/tools/pgtest. This seems to be a platform-specific reimplementation of 'make clean; make check'. Why bother? Marc requested it. Is

Re: [HACKERS] O_DIRECT in freebsd

2003-06-22 Thread Bruce Momjian
Basically, we don't know when we read a buffer whether this is a read-only or read/write. In fact, we could read it in, and another backend could write it for us. The big issue is that when we do a write, we don't wait for it to get to disk. It seems to use O_DIRECT, we would have to read the

Re: [HACKERS] PlPython

2003-06-22 Thread Tom Lane
Kevin Jacobs [EMAIL PROTECTED] writes: Attached is a patch that removes all of the RExec code from plpython from the current PostgreSQL CVS. In addition, plpython needs to be changed to an untrusted language in createlang. I am inclined to rename plpython to plpythonu, by analogy to pltclu.

Re: [HACKERS] O_DIRECT in freebsd

2003-06-22 Thread Sean Chittenden
Basically, we don't know when we read a buffer whether this is a read-only or read/write. In fact, we could read it in, and another backend could write it for us. Um, wait. The cache is shared between backends? I don't think so, but it shouldn't matter because there has to be a semaphore

Re: [HACKERS] O_DIRECT in freebsd

2003-06-22 Thread Bruce Momjian
Sean Chittenden wrote: Basically, we don't know when we read a buffer whether this is a read-only or read/write. In fact, we could read it in, and another backend could write it for us. Um, wait. The cache is shared between backends? I don't think so, but it shouldn't matter because

Re: [HACKERS] O_DIRECT in freebsd

2003-06-22 Thread Sean Chittenden
Basically, we don't know when we read a buffer whether this is a read-only or read/write. In fact, we could read it in, and another backend could write it for us. Um, wait. The cache is shared between backends? I don't think so, but it shouldn't matter because there has to be a

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: I sure want two-phase commit. I don't remember it as being rejected, and we certainly need it, independent of replication. Is 2PC a real-world solution to any real-world problem? I have never seen a satisfactory explanation of what you do when you've

Re: [HACKERS] O_DIRECT in freebsd

2003-06-22 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: Basically, I think we need free-behind rather than O_DIRECT. There are two separate issues here --- one is what's happening in our own cache, and one is what's happening in the kernel disk cache. Implementing our own free-behind code would help in our own

Re: [HACKERS] O_DIRECT in freebsd

2003-06-22 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: _That_ is an excellent point. However, do we know at the time we open the file descriptor if we will be doing this? We'd have to say on a per-read basis whether we want O_DIRECT or not, and fd.c would need to provide a suitable file descriptor. What

Re: [HACKERS] a problem with index and user define type

2003-06-22 Thread Weiping He
Tom Lane wrote: Wang Mike [EMAIL PROTECTED] writes: but this query: select * from test_uuid where id = 'df2b10aa-a31d-11d7-9867-0050babb6029'::uuid dosn't use index QUERY PLAN --- Seq Scan on

Re: [HACKERS] O_DIRECT in freebsd

2003-06-22 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Basically, I think we need free-behind rather than O_DIRECT. There are two separate issues here --- one is what's happening in our own cache, and one is what's happening in the kernel disk cache. Implementing our own free-behind code

Re: [HACKERS] O_DIRECT in freebsd

2003-06-22 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: _That_ is an excellent point. However, do we know at the time we open the file descriptor if we will be doing this? We'd have to say on a per-read basis whether we want O_DIRECT or not, and fd.c would need to provide a suitable file

Re: [HACKERS] O_DIRECT in freebsd

2003-06-22 Thread Sean Chittenden
Basically, I think we need free-behind rather than O_DIRECT. There are two separate issues here --- one is what's happening in our own cache, and one is what's happening in the kernel disk cache. Implementing our own free-behind code would help in our own cache but does nothing for the

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I sure want two-phase commit. I don't remember it as being rejected, and we certainly need it, independent of replication. Is 2PC a real-world solution to any real-world problem? I have never seen a satisfactory explanation of what

Re: [HACKERS] O_DIRECT in freebsd

2003-06-22 Thread Sean Chittenden
What about cache coherency problems with other backends not opening with O_DIRECT? If O_DIRECT introduces cache coherency problems against other processes not using O_DIRECT then the whole idea is a nonstarter, but I can't imagine any kernel hackers would have been stupid enough

Re: [HACKERS] O_DIRECT in freebsd

2003-06-22 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: True, it is a cost/benefit issue. My assumption was that once we have free-behind in the PostgreSQL shared buffer cache, the kernel cache issues would be minimal, but I am willing to be found wrong. If you are running on the

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread The Hermit Hacker
On Sun, 22 Jun 2003, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I sure want two-phase commit. I don't remember it as being rejected, and we certainly need it, independent of replication. Is 2PC a real-world solution to any real-world problem? I

Re: [HACKERS] O_DIRECT in freebsd

2003-06-22 Thread Tom Lane
Sean Chittenden [EMAIL PROTECTED] writes: it doesn't seem totally out of the question. I'd kinda like to see some experimental evidence that it's worth doing though. Anyone care to make a quick-hack prototype and do some measurements? What would you like to measure? Overall system

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: I think it's a cool-sounding phrase that does not actually work in practice. I think 2PC can be used to build more complex features, Only if it works to begin with. If it's unreliable, what are you gonna build on it?

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: I think it's a cool-sounding phrase that does not actually work in practice. I think 2PC can be used to build more complex features, Only if it works to begin with. If it's unreliable, what are you gonna build

Re: [HACKERS] a problem with index and user define type

2003-06-22 Thread Tom Lane
Weiping He [EMAIL PROTECTED] writes: the situation trun worse: now the explain shows the query using the index, the we can't select out the match row! Any hint about what's wrong with us? My bet: either your operators are broken or your operator class definition is wrong.

Re: [HACKERS] O_DIRECT in freebsd

2003-06-22 Thread Sean Chittenden
True, it is a cost/benefit issue. My assumption was that once we have free-behind in the PostgreSQL shared buffer cache, the kernel cache issues would be minimal, but I am willing to be found wrong. If you are running on the small-shared-buffers-and-large-kernel-cache theory, then

Re: [HACKERS] O_DIRECT in freebsd

2003-06-22 Thread Bruce Momjian
Sean Chittenden wrote: Nor could it ever be a win unless the cache was populated via O_DIRECT, actually. Big PG cache == 2 extra copies of data, once in the kernel and once in PG. Doing caching at the kernel level, however means only one copy of data (for the most part). Only problem with

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: The question was whether 2PC is useful. The question wasn't if an unreliable 2PC was useful. My question is whether there is such a thing as reliable 2PC. I sure don't see how you build that. regards, tom lane

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: The question was whether 2PC is useful. The question wasn't if an unreliable 2PC was useful. My question is whether there is such a thing as reliable 2PC. I sure don't see how you build that. Other databases use 2PC --- are you

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Jan Wieck
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I sure want two-phase commit. I don't remember it as being rejected, and we certainly need it, independent of replication. Is 2PC a real-world solution to any real-world problem? I have never seen a satisfactory explanation of what you do

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: Other databases use 2PC --- are you saying none of them are reliable? Perhaps they're just smarter than I am. My question stands: what do you do when the controller doesn't respond after you promise to commit? Without a believable answer to that, I have

Re: [HACKERS] ECPG still having thread problems - follow-up

2003-06-22 Thread Philip Yarra
On Wed, 18 Jun 2003 02:58 pm, Philip Yarra wrote: Hi all, it looks like Lee's ECPG (and libpq) thread-safety patches have been applied, and configure --with-threads is also added. I have been doing some testing, and I still encounter a threading problem. For those interested, I tested this on

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Sailesh Krishnamurthy
Bruce == Bruce Momjian [EMAIL PROTECTED] writes: Bruce Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: The question was whether 2PC is useful. The question wasn't if an unreliable 2PC was useful. My question is whether there is such a thing as reliable

Re: [HACKERS] $PostgreSQL$ for revision info

2003-06-22 Thread Bruce Momjian
Added to TODO: * Change CVS $Id$ to $PostgreSQL$ --- Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Is this a dead issue? I know several people said they wanted it. I'm willing to do it if people

Re: [HACKERS] O_DIRECT in freebsd

2003-06-22 Thread Sean Chittenden
it doesn't seem totally out of the question. I'd kinda like to see some experimental evidence that it's worth doing though. Anyone care to make a quick-hack prototype and do some measurements? What would you like to measure? Overall system performance when a query is using O_DIRECT

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Tom Lane
Jan Wieck [EMAIL PROTECTED] writes: The other problem I was missing being addressed is what happens if one promised I can commit and crashes? Not exactly at the time he crashes, but more at the time he restarts? Doesn't he have to restart into exactly that state of I can commit, with all

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Tom Lane
Sailesh Krishnamurthy [EMAIL PROTECTED] writes: I'm not sure if I understand Tom's beef - I think he is concerned about what happens if a subordinate does not respond to a prepare message. I would assume that the co-ordinator would not let the commit go through until it has received

Re: [HACKERS] O_DIRECT in freebsd

2003-06-22 Thread Sean Chittenden
Nor could it ever be a win unless the cache was populated via O_DIRECT, actually. Big PG cache == 2 extra copies of data, once in the kernel and once in PG. Doing caching at the kernel level, however means only one copy of data (for the most part). Only problem with this being that

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Christopher Kings-Lynne
No. I want to know what the subordinate does when it's promised to commit and the co-ordinator never responds. AFAICS the subordinate is screwed --- it can't commit, and it can't abort, and it can't expect to make progress indefinitely on other work while it's holding locks for the

Re: [HACKERS] O_DIRECT in freebsd

2003-06-22 Thread Bruce Momjian
Sean Chittenden wrote: Nor could it ever be a win unless the cache was populated via O_DIRECT, actually. Big PG cache == 2 extra copies of data, once in the kernel and once in PG. Doing caching at the kernel level, however means only one copy of data (for the most part). Only

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread The Hermit Hacker
On Sun, 22 Jun 2003, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: I think it's a cool-sounding phrase that does not actually work in practice. I think 2PC can be used to build more complex features, Only if it works to begin

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread The Hermit Hacker
On Mon, 23 Jun 2003, Sailesh Krishnamurthy wrote: I'm not sure if I understand Tom's beef - I think he is concerned about what happens if a subordinate does not respond to a prepare message. I would assume that the co-ordinator would not let the commit go through until it has received

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread The Hermit Hacker
On Mon, 23 Jun 2003, Christopher Kings-Lynne wrote: No. I want to know what the subordinate does when it's promised to commit and the co-ordinator never responds. AFAICS the subordinate is screwed --- it can't commit, and it can't abort, and it can't expect to make progress indefinitely

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Tom Lane
The Hermit Hacker [EMAIL PROTECTED] writes: Hrmmm, I see Tom's point (I think!) ... but what if, for instance, the co-ordinator crashes? Or you just lose the network connection for awhile. The worst case scenario I think is where the co-ordinator got everyone's promise to commit, and told some

[HACKERS] 2Q implementaion for PostgreSQL buffer replacement.

2003-06-22 Thread Yutaka tanida
Hi. I implement 2Q algorithm to PostgreSQL for buffer management , instead of LRU. It's known as low overhead and high performance than LRU. If you have some interests , see following URL. http://www.vldb.org/conf/1994/P439.PDF In my test (pgbench -S) , it improves 4% cache hit rate and 2% up

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Sailesh Krishnamurthy
Tom == Tom Lane [EMAIL PROTECTED] writes: Tom Sailesh Krishnamurthy [EMAIL PROTECTED] writes: I'm not sure if I understand Tom's beef - I think he is concerned about what happens if a subordinate does not respond to a prepare message. I would assume that the co-ordinator

Re: [HACKERS] Two weeks to feature freeze

2003-06-22 Thread Mike Mascari
Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: Hrmmm, I see Tom's point (I think!) ... but what if, for instance, the co-ordinator crashes? Or you just lose the network connection for awhile. The worst case scenario I think is where the co-ordinator got everyone's promise to

Re: [GENERAL] [HACKERS] large objects

2003-06-22 Thread Bruce Momjian
Add to TODO: * Allow SSL-enabled clients to turn off SSL transfers --- Tom Lane wrote: Nigel J. Andrews [EMAIL PROTECTED] writes: Ok, I tried to try this but I can not get SSL to _not_ be used when connecting