Thread: Press Release and eRServer
Is it really the ideal solution that the first item in the press release of PostgreSQL is eRServer? I don't mind mentioning auxilliary software, but I think the press release of PostgreSQL should primarily concern the software PostgreSQL. Also, one might say that the release of eRServer is already "old news", which had its own press release that went out over two months ago. Am I looking at the latest version here? -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > Is it really the ideal solution that the first item in the press release > of PostgreSQL is eRServer? I don't mind mentioning auxilliary software, > but I think the press release of PostgreSQL should primarily concern the > software PostgreSQL. Also, one might say that the release of eRServer is > already "old news", which had its own press release that went out over two > months ago. Am I looking at the latest version here? > Makese sense --- eRServer is something that should be near the bottom. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Peter, > Is it really the ideal solution that the first item in the press release > of PostgreSQL is eRServer? I don't mind mentioning auxilliary software, > but I think the press release of PostgreSQL should primarily concern the > software PostgreSQL. Also, one might say that the release of eRServer is > already "old news", which had its own press release that went out over two > months ago. Am I looking at the latest version here? Probably not. What version are you looking at? -- Josh Berkus Aglio Database Solutions San Francisco
>>Is it really the ideal solution that the first item in the press release >>of PostgreSQL is eRServer? I don't mind mentioning auxilliary software, >>but I think the press release of PostgreSQL should primarily concern the >>software PostgreSQL. >> I agree with this. Press Releases about PostgreSQL should be about PostgreSQL. eRserver is not a PostgreSQL product (core distribution) unlike something like plpython or something. If it is not part of the core distribution it should be left to sub items or honorable mentions. Joshua D. Drake >>Also, one might say that the release of eRServer is >>already "old news", which had its own press release that went out over two >>months ago. Am I looking at the latest version here? >> >> > >Probably not. What version are you looking at? > > > -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org
I agree with this. Press Releases about PostgreSQL should be about PostgreSQL. eRserver is not a PostgreSQL product (core distribution) unlike something like plpython or something. <snip> I'll Devil's Advocate a bit... Some points about replication: * The 'other' open source database makes a lot of noise about replication, especially wrt postgres * Replication is an enterprise buzzword * It helps 'sell' the 7.4 release a bit (not that it needs it, feature packed already) [that said, I agree with what you & Peter said] Merlin
Guys, First off: The release mentions eRServer in passing, in the context of "high-availablity enterprise postgres". So I don't think that needs to be changed. For the Press Kit, where the more substantial mention is, we have 3 choices: 1) Delete the paragraph; 2) Move the paragraph "down" thus reducing its priority 3) leave things the way they are. -- -Josh Berkus Aglio Database Solutions San Francisco
This paragraph: HIGH AVAILABILITY Expansion of PostgreSQL's Free Space Map disk management feature to support continuous index maintenance is the last "piece of the puzzle" in providing 24/7/365 uptime for PostgreSQL databases. The many hardware solutions vendors who include PostgreSQL as the embedded database in their applications may now eliminate the need for any data locking or downtime in their applications. I believe is false. As long as you have to vacuum the above is not true. Also as long as their is a potential that we have to use the reindex command the above isn't true. Anything that the "system" requires (which does not include transactions) that causes a lock for any period of time would invalidate the above. Sincerely, Joshua Drake Josh Berkus wrote: >Guys, > >First off: The release mentions eRServer in passing, in the context of >"high-availablity enterprise postgres". So I don't think that needs to be >changed. > >For the Press Kit, where the more substantial mention is, we have 3 choices: > >1) Delete the paragraph; >2) Move the paragraph "down" thus reducing its priority >3) leave things the way they are. > > > -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org
If the index bloat is fixed (we haven't seen firm evidence one way or 'tother yet) AND you were running the pg_autovacuum daemon by default, then that would get you there. I wonder if it's possible to have the pg_autovacuum daemon eventually move into the core once it's tested, so that a simple GUC setting will turn it on or off? Is that part of the eventual plan? On Wed, 29 Oct 2003, Joshua D. Drake wrote: > This paragraph: > > HIGH AVAILABILITY > Expansion of PostgreSQL's Free Space Map disk management feature to support > continuous index maintenance is the last "piece of the puzzle" in providing > 24/7/365 uptime for PostgreSQL databases. The many hardware solutions vendors > who include PostgreSQL as the embedded database in their applications may now > eliminate the need for any data locking or downtime in their applications. > > > I believe is false. As long as you have to vacuum the above is not true. Also > as long as their is a potential that we have to use the reindex command the above > isn't true. Anything that the "system" requires (which does not include transactions) > that causes a lock for any period of time would invalidate the above. > > Sincerely, > > Joshua Drake > > > > Josh Berkus wrote: > > >Guys, > > > >First off: The release mentions eRServer in passing, in the context of > >"high-availablity enterprise postgres". So I don't think that needs to be > >changed. > > > >For the Press Kit, where the more substantial mention is, we have 3 choices: > > > >1) Delete the paragraph; > >2) Move the paragraph "down" thus reducing its priority > >3) leave things the way they are. > > > > > > > >
Josh, First of all, be aware that we have already collected half the translations for the press kit. So at this point, we can only cut paragraphs and not edit. These comments would have been more timely a month ago .... > I believe is false. As long as you have to vacuum the above is not true. How? Vacuuming does not require the database to be offline. Vacuum full does, but that can be eliminated with proper tuning. Also > as long as their is a potential that we have to use the reindex command the above > isn't true. But reindex can now be eliminated if the FSM is tuned right. > Anything that the "system" requires (which does not include transactions) > that causes a lock for any period of time would invalidate the above. And the whole point of the FSM feature is that most databases, with proper tuning, should not require any maintainence which needs exclusive locking. If anybody has evidence that the FSM index management doens't work, then we'll cut the paragraph. However, I'm inclined to trust Tom & Co., and my only simple tests seemed to uphold the Lazy-Vacuum-ability of indexes. -- -Josh Berkus Aglio Database Solutions San Francisco
On Wed, 2003-10-29 at 17:24, Josh Berkus wrote:
> If anybody has evidence that the FSM index management doens't work, then we'll
> cut the paragraph. However, I'm inclined to trust Tom & Co., and my only
> simple tests seemed to uphold the Lazy-Vacuum-ability of indexes.
Tom has laid out at least one case where the potential for index growth
exits, though I don't see it in a quick search of the archives...
Tom, can you weigh in here?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Hello, After review of the press kit. I think it should be moved down. Sincerely, Joshua D. Drake Josh Berkus wrote: >Guys, > >First off: The release mentions eRServer in passing, in the context of >"high-availablity enterprise postgres". So I don't think that needs to be >changed. > >For the Press Kit, where the more substantial mention is, we have 3 choices: > >1) Delete the paragraph; >2) Move the paragraph "down" thus reducing its priority >3) leave things the way they are. > > > -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org
First of all, be aware that we have already collected half the translations >for the press kit. So at this point, we can only cut paragraphs and not >edit. These comments would have been more timely a month ago .... > > > If only I had a nickel :) >>I believe is false. As long as you have to vacuum the above is not true. >> >> > >How? Vacuuming does not require the database to be offline. Vacuum full >does, but that can be eliminated with proper tuning. > > > No but vacuum will cause your machine to grind to a crawl. Try telling a customer that is pushing 240,000 transactions an hour, 24 hours a day to run a Vacuum. They are not pleased. Don't get me wrong. I want to promote as much as the next guy but that paragraph is pretty strong. >And the whole point of the FSM feature is that most databases, with proper >tuning, should not require any maintainence which needs exclusive locking. > >If anybody has evidence that the FSM index management doens't work, then we'll >cut the paragraph. However, I'm inclined to trust Tom & Co., and my only >simple tests seemed to uphold the Lazy-Vacuum-ability of indexes. > > > I could have sworn that Tom said that it might not be fixed. Was that ever investigated? -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org
Robert Treat wrote: > On Wed, 2003-10-29 at 17:24, Josh Berkus wrote: > > If anybody has evidence that the FSM index management doens't work, then we'll > > cut the paragraph. However, I'm inclined to trust Tom & Co., and my only > > simple tests seemed to uphold the Lazy-Vacuum-ability of indexes. > > Tom has laid out at least one case where the potential for index growth > exits, though I don't see it in a quick search of the archives... > > Tom, can you weigh in here? If you delete all but one row on every index page, I think. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On 29 Oct 2003, Robert Treat wrote: > On Wed, 2003-10-29 at 17:24, Josh Berkus wrote: > > If anybody has evidence that the FSM index management doens't work, then we'll > > cut the paragraph. However, I'm inclined to trust Tom & Co., and my only > > simple tests seemed to uphold the Lazy-Vacuum-ability of indexes. > > Tom has laid out at least one case where the potential for index growth > exits, though I don't see it in a quick search of the archives... > > Tom, can you weigh in here? I thought that was more the case where indexes may be up to 33% larger than they would be if they were created staticly, but no more. Or something like that. If the possible maximum size of a vacuumed index is 1/3 or so greater than the most compact size, I wouldn't consider that bloated. not like the old way, where you'd have tons of dead nodes in the btree index.
On Wed, 29 Oct 2003, Joshua D. Drake wrote: > First of all, be aware that we have already collected half the translations > > >for the press kit. So at this point, we can only cut paragraphs and not > >edit. These comments would have been more timely a month ago .... > > > > > > > If only I had a nickel :) > > >>I believe is false. As long as you have to vacuum the above is not true. > >> > >> > > > >How? Vacuuming does not require the database to be offline. Vacuum full > >does, but that can be eliminated with proper tuning. > > > > > > > No but vacuum will cause your machine to grind to a crawl. Try telling a > customer > that is pushing 240,000 transactions an hour, 24 hours a day to run a > Vacuum. > They are not pleased. The autovacuum daemon makes this situation as good as it's likely to ever get without some form of "vacuum this tuple at your leisure when you've got free bandwidth" setting for an update/delete. It only vacuums the tables that have actually been changing, and you can set the period and what not so that it runs often enough that it never has too much to do. Keep in mind, the garbage collection HAS to happen sometime, so even if it were rolled 100% efficiently into the individual update/delete itself, it would still cost, just with slower transactions. I agree though that the paragraph may make it sound like automatic vacuuming is a default part of the install when it isn't.
Guys, > > I agree though that the paragraph may make it sound like automatic > vacuuming is a default part of the install when it isn't. Well, like I said, we can't edit at this point, only cut. So the question is, do we cut the paragraph completely or not? Incidentally, I'd like to point out that I solicited help on this list 6 weeks ago for re-writing that specific paragraph, and nobody volunteered except Neil who cut 1/2 sentence. -- -Josh Berkus Aglio Database Solutions San Francisco
>Incidentally, I'd like to point out that I solicited help on this list 6 weeks >ago for re-writing that specific paragraph, and nobody volunteered except >Neil who cut 1/2 sentence. > > > Well in my own defense, I should have responded sooner :) -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org
Josh, > >Incidentally, I'd like to point out that I solicited help on this list 6 weeks > >ago for re-writing that specific paragraph, and nobody volunteered except > >Neil who cut 1/2 sentence. > Well in my own defense, I should have responded sooner :) Yeah, I'm just frustrated because I haven't been able to get much help managing the release PR, and it's not really work I enjoy doing. I'm sure that Tom & Bruce feel the same way sometimes about maintaining some of our code .... Anyway, it's the 11th hour righ now, and we need to make a decision BY TOMMORROW: do we keep that paragraph and its hyperbole, or do we cut it and miss a chance to brag about a frequently-requested feature? Incidentally, the paragraph did originally cover PGAVD as well, but that got cut when Neil informed me that PGAVD was still beta. So maybe it's fluffy enough now that it needs to be cut. Vote? -- -Josh Berkus Aglio Database Solutions San Francisco
On Wed, 2003-10-29 at 18:21, Josh Berkus wrote: > Guys, > > > > > I agree though that the paragraph may make it sound like automatic > > vacuuming is a default part of the install when it isn't. > > Well, like I said, we can't edit at this point, only cut. So the question > is, do we cut the paragraph completely or not? Leave it in place. Speed during vacuum is an issue (Jan shows Vacuum can be improved) it does not impede the 24hour availability statement. Indexes may grow larger than wanted. Indexes do have an upper limit to their growth for a given dataset size. As someone who ends up with sparse indexes (multiple entries are aggregated into a single entry but in the same index key area) I wish data could be shuffled in the index -- but after a few years when the data is finally removed those index pages do become available for reuse. Of course, if you have a dataset that constantly grows, indexes could take a fair amount of space BUT you have a constantly growing dataset anyway. One would assume additional storage requirements would be accounted for somewhere. Nowhere do I read unmonitored 24/7/365 availability or ultra-fast always peak speed availability. 7.4 may have it's speed bumps but it will be responding to queries.
Attachment
>Nowhere do I read unmonitored 24/7/365 availability or ultra-fast always >peak speed availability. 7.4 may have it's speed bumps but it will be >responding to queries. > > Not if it is a vacuum full and you are trying to do an insert. Which is exactly what I am talking about. Doing a vacuum full on a table that has had 5.7 million inserts/updates/deletes during the last 23 hours is going to cause a rather long vacuum full which in turn will cause a rather long period of unavailability of the database. I am not trying to push either way here at this point but I do think it is important that we are honest about the realities otherwise we end up looking like that other open source database. Sincerely, Joshua Drake -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org
Josh,
> Not if it is a vacuum full and you are trying to do an insert. Which is
> exactly what
> I am talking about. Doing a vacuum full on a table that has had 5.7 million
> inserts/updates/deletes during the last 23 hours is going to cause a rather
> long vacuum full which in turn will cause a rather long period of
> unavailability
> of the database.
But if you've set it up correctly in the first place, the vacuum full won't be
necessary.
--
-Josh Berkus
______AGLIO DATABASE SOLUTIONS___________________________
Josh Berkus
Complete information technology josh@agliodbs.com
and data management solutions (415) 565-7293
for law firms, small businesses fax 621-2533
and non-profit organizations. San Francisco
Hello, O.k. maybe I am missing something.. but what can I do to make it so a vacuum full isn't required? Is this some 7.4 magic that I don't know about? J Josh Berkus wrote: >Josh, > > > >>Not if it is a vacuum full and you are trying to do an insert. Which is >>exactly what >>I am talking about. Doing a vacuum full on a table that has had 5.7 million >>inserts/updates/deletes during the last 23 hours is going to cause a rather >>long vacuum full which in turn will cause a rather long period of >>unavailability >>of the database. >> >> > >But if you've set it up correctly in the first place, the vacuum full won't be >necessary. > > > -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org
On Wed, 2003-10-29 at 19:08, Joshua D. Drake wrote: > >Nowhere do I read unmonitored 24/7/365 availability or ultra-fast always > >peak speed availability. 7.4 may have it's speed bumps but it will be > >responding to queries. > > > > > Not if it is a vacuum full and you are trying to do an insert. Which is > exactly what Why are you running a vacuum full -- forgot to do a regular vacuum often enough? PostgreSQL also won't be answering queries if I unplug the machine it is on, toss it into the back of a plane and fly it to another data centre. We should only be considering standard operation.
Attachment
Josh, > O.k. maybe I am missing something.. but what can I do to make it so a > vacuum full > isn't required? Is this some 7.4 magic that I don't know about? "magic" we've had since 7.2.0, Josh. If your max_fsm_pages is set to higher than the level of data pages you recycle between vacuums, and you don't run out of memory on the machine for significant periods, then you need never do a vacuum_full. The functionality in 7.4 extends this to indexes, eliminating the REINDEX in most cases. -- -Josh Berkus Aglio Database Solutions San Francisco
>If your max_fsm_pages is set to higher than the level of data pages you >recycle between vacuums, and you don't run out of memory on the machine for >significant periods, then you need never do a vacuum_full. > > > I knew that it would delay the need for a vacuum full but I didn't know it could potentially eliminate it. O.k. >The functionality in 7.4 extends this to indexes, eliminating the REINDEX in >most cases. > > > Interesting. -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org
>Why are you running a vacuum full -- forgot to do a regular vacuum often >enough? > No because if we don't run a vacuum full on this (actually a couple of) machine then the machine slows down to a crawl over time. Vacuums are run every 4 or 5 hours and a vacuum full every night. I am obviously missing something and relying on past knowledge. J >PostgreSQL also won't be answering queries if I unplug the >machine it is on, toss it into the back of a plane and fly it to another >data centre. > > > O.k. this was a ridiculous analogy. >We should only be considering standard operation. > > -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - jd@commandprompt.com - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org
Josh, > I knew that it would delay the need for a vacuum full but I didn't know > it could > potentially eliminate it. O.k. Sure. I've got one project where the client hasn't had a VACUUM FULL in 1.5 years. REINDEX, on the other hand .... Of course, this doesn't work for all databases. DBs that involve huge data transformations would require preposterously high FSM settings. -- -Josh Berkus Aglio Database Solutions San Francisco
On Wed, 2003-10-29 at 19:57, Joshua D. Drake wrote: > >Why are you running a vacuum full -- forgot to do a regular vacuum often > >enough? > > > No because if we don't run a vacuum full on this (actually a couple of) > machine > then the machine slows down to a crawl over time. Vacuums are run every > 4 or 5 hours > and a vacuum full every night. > > I am obviously missing something and relying on past knowledge. Yup.. Sounds like fsm is too low. Bump it up an order of magnitude and vacuum hourly instead -- drop the FULL. > >PostgreSQL also won't be answering queries if I unplug the > >machine it is on, toss it into the back of a plane and fly it to another > >data centre. > > > O.k. this was a ridiculous analogy. Not really.. I see to do the data centre move more often than a VACUUM FULL.
Attachment
I think we should keep the replication part and the press release as is. My points are: 1) We have translated it to many languages. It's not a good idea to change something you don't know very close to the release. I would not change any code either, if I can choose not to. 2) I think replication is important. If you have only one database server, and you can't replicate, it is quite difficult to make a reliable system. What if something in the computer is burning? I bet the computer is shut down. No matter how hot-swapping stuff you have inside. 3) Does it matter, who made it? If it is now open source, does the user care, if it was originally made by a community or not, if the community says that they now support it? If it solves the issue that we move the replication part some paragphs lower, then is it really so important that we should move it at this time? 4) I think this is the point, where the community really says, that it is going to support the replication. Earlier on it was just that it was donated. 5) This is the first release made, that supports replication. The 7.3 supports replication now, but when it was made, it didn't. So we can say, that replication was considered, when this version was designed. About the vacuum, well, if you can replicate, then you can propably do some balancing to make sure, that you always have a server up and running. For example, you have 3 servers. You take 1 offline and run vacuum. You join it back, and do the next etc. Okay, if you have only one database, like in some embedded systems, I can believe it can be the case, that it slows down sometimes. I think it can be accepted. I think that this is more of a documentation issue, than an issue on the press release. When I read a press release, I usually don't believe half of it. Even less, if it is US originated. If there is then someone, who has very high load all the time, I think they will test different solutions, and choose one, the one they think matches their needs. But they don't choose the system based on a press release. I also follow the Linux kernel stuff, and I noticed an article, where Linus says that he would like companies to test the current test version. I think that postgresql could have a similar approach. We could say, that here is the 7.4 beta x. This version supports xxx. Then, if people say that it has problems running on for example AS/400, we could say that on the release and fix it later. Linus has the idea, that he can't test everything, but that when about 99,99% of the users are happy, he can make a new release. I think we could use release notes in beta versions to test the stuff later put in press releases. This way we would perhaps get some feedback on the issues before the actual release. I haven't read anything in the advocacy list during the past couple of weeks that would support the idea of changing the press release. So I vote that we should keep it as is. Jussi
On Wed, 29 Oct 2003, Rod Taylor wrote: > On Wed, 2003-10-29 at 19:57, Joshua D. Drake wrote: > > >Why are you running a vacuum full -- forgot to do a regular vacuum often > > >enough? > > > > > No because if we don't run a vacuum full on this (actually a couple of) > > machine > > then the machine slows down to a crawl over time. Vacuums are run every > > 4 or 5 hours > > and a vacuum full every night. > > > > I am obviously missing something and relying on past knowledge. > > Yup.. Sounds like fsm is too low. Bump it up an order of magnitude and > vacuum hourly instead -- drop the FULL. I'd actually highly recommend the autovacuum daemon with moderately aggressive settings, i.e. have it come on and check every 5 or 10 minutes. On a table that's being updated many times a second, the needs for vacuuming can be very frequent. let the autovacuum daemon do it. You can schedule in mandatory plain vacuum s every couple of hours to make sure they happen if you're paranoide, but honestly, while the autovacuum daemon may technically be beta, it seems to be working for an awful lot of people with heavily updated sites.
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Robert Treat wrote:
>> Tom has laid out at least one case where the potential for index growth
>> exits, though I don't see it in a quick search of the archives...
>>
>> Tom, can you weigh in here?
> If you delete all but one row on every index page, I think.
It might be worth pointing out that while one entry per page would be
pretty grim, it's at least a *bounded* overhead factor. Pre-7.4 it was
possible to accumulate arbitrarily large numbers of entirely empty pages
in an index, so that the total index size could grow without bound even
when the actual number of live entries stayed about constant.
Furthermore, this worst case actually happened in a significant fraction
of real-world usages. The cases where 7.4 will degrade to a small
number of live entries per page are (probably) far more infrequent.
So I think 7.4 will greatly reduce the need for routine reindexing ...
but it's probably premature to claim that it's gone entirely.
regards, tom lane
Robert, I've been e-mailing you about an urgent matter for a couple of weeks, and getting no response. I think you're not getting my e-mails. Please contact me. Phone is OK too: 415-565-7293 -- -Josh Berkus Aglio Database Solutions San Francisco