State of Beta 2

[Network Administrator]

Re: State of Beta (2)

That sounds good save two things. We need to state what are the project run
dates and what happens at or around the due date. That to say we have the
deliverable for testing (beta ready), more time is needed to complete core
features (alpha ready) and therefore more funds are needed, project is one hold
due to features needed outside the scope of the project, etc, etc, etc...

You get the idea.

Quoting "Joshua D. Drake" <jd@commandprom pt.com>:
[color=blue]
> Hello,
>
> O.k. here are my thoughts on how this could work:
>
> Command Prompt will set up an escrow account online at www.escrow.com.
> When the Escrow account totals 2000.00 and is released, Command Prompt
> will dedicate a
> programmer for one month to debugging, documenting, reviewing,
> digging, crying,
> screaming, begging and bleeding with the code. At the end of the month
> and probably during
> depending on how everything goes Command Prompt will release its
> findings. The findings
> will include a project plan on moving forward over the next 5 months
> (if that is what it takes) to
> produce the first functional pg_upgrade.
>
> If the project is deemed as moving in the right direction by the
> community members and specifically
> the core members we will setup milestone payments for the project.
>
> What does everyone think?
>
> Sincerely,
>
> Joshua D. Drake
>
>
> Dennis Gearon wrote:
>[color=green]
> > I had already committed $50/mo.
> >
> > Robert Creager wrote:
> >[color=darkred]
> >> Once upon a time (Tue, 16 Sep 2003 21:26:05 -0700)
> >> Dennis Gearon <gearond@firese rve.net> uttered something amazingly
> >> similar to:
> >>
> >>
> >>
> >>> Robert Creager wrote:
> >>>
> >>>
> >>>
> >>>> Once upon a time (Tue, 16 Sep 2003 12:59:37 -0700)
> >>>> "Joshua D. Drake" <jd@commandprom pt.com> uttered something
> >>>> amazingly similar
> >>>> to:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> If someone is willing to pony up 2000.00 per month for a period of
> >>>>> at
> >>>>
> >>>> Well, if you're willing to set up some sort of escrow, I'll put in
> >>>> $100. I
> >>>>
> >>>
> >>> Is that $100 times once, or $100 X 6mos anticiapated develop time.
> >>>
> >>
> >>
> >> That's $100 once. And last I looked, there are well over 1800
> >> subscribers on
> >> this list alone. On the astronomically small chance everyone one of
> >> them did
> >> what I'm doing, it would cover more than 6 months of development time
> >> ;-) This
> >> strikes me as like supporting public radio. The individuals do some,
> >> and the
> >> corporations do a bunch.
> >>
> >> I'm just putting my money toward a great product, rather than
> >> complaining that
> >> it's not done. Just like Joshua is doing. You cannot hire a competent
> >> programmer for $24k a year, so he is putting up some money on this also.
> >>
> >> There have been a couple of other bytes from small businesses, so who
> >> knows!
> >>
> >> You game?
> >>
> >> Cheers,
> >> Rob
> >>
> >>
> >>[/color][/color]
>
> --
> 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@commandpromp t.com - http://www.commandprompt.com
> The most reliable support for the most reliable Open Source database.
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>[/color]


--
Keith C. Perry
Director of Networks & Applications
VCSN, Inc.

http://vcsn.com

_______________ _______________ ______
This email account is being host by:
VCSN, Inc : http://vcsn.com

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Manfred Koizar]

Re: State of Beta 2

On Thu, 18 Sep 2003 12:11:18 -0400, Lamar Owen <lowen@pari.edu > wrote:[color=blue]
>Marc G. Fournier wrote:[color=green]
>> [...] upgrading is a key feature [...][/color]
> a migration tool
>that could read the old format _without_a_runn ing_old_backend _ [...]
> the new backend is powerless to recover the old data.
> OS upgrades [...], FreeBSD ports upgrades, and RPM
>upgrades are absolutely horrid at this point. [...]
>[censored] has a better system than we
>[...] the pain of upgrading [...]
>*I* should complain about a ramble? :-)[/color]

Lamar, I *STRONGLY* agree with almost everything you say here and in
other posts, except perhaps ...

You et al. seem to think that system catalog changes wouldn't be a
problem if only we could avoid page format changes. This is not
necessarily so. Page format changes can be handled without much
effort, if

.. the changes are local to each page (the introduction of a level
indicator in btree pages is a counter-example),

.. we can tell page type and version for every page,

.. the new format does not need more space than the old one.

You wrote earlier:
| the developers who changed the on-disk format ...

Oh, that's me, I think. I am to blame for the heap tuple header
changes between 7.2 and 7.3; Tom did some cleanup work behind me but
cannot be held responsible for the on-disk-format incompatibiliti es.
I'm not aware of any other changes falling into this category for 7.3.
So you might as well have used the singular form ;-)

| ... felt it wasn't important to make it continue working.

This is simply not true. Seamless upgrade is *very* important, IMHO.
See http://archives.postgresql.org/pgsql...6/msg00136.php
for example, and please keep in mind that I was still very "fresh" at
that time. Nobody demanded that I keep my promise and I got the
impression that a page format conversion tool was not needed because
there wouldn't be a pg_upgrade anyway.

Later, in your "Upgrading rant" thread, I even posted some code
(http://archives.postgresql.org/pgsql.../msg00294.php).
Unfortunately this went absolutely unnoticed, probably because it
looked so long because I fat-fingered the mail and included the code
twice. :-(
[color=blue]
>It's all
>in the archives that nobdy seems willing to read over again. Why do we
>even have archives if they're not going to be used?[/color]

Sic!

While I'm at it, here are some comments not directly addressed to
Lamar:

Elsewhere in this current thread it has been suggested that the
on-disk format will stabilize at some time in the future and should
then be frozen to ensure painless upgrades. IMHO, at the moment when
data structures are declared stable and immutable the project is dead.

And I don't believe the myth that commercial database vendors have
reached a stable on-disk representation. Whoever said this, is kindly
asked to reveal his source of insight.

A working pg_upgrade is *not* the first thing we need. What we need
first is willingness to not break backwards compatibility. When
Postgres adopts a strategy of not letting in any change unless it is
fully compatible with the previous format or accompanied by an upgrade
script/program/whatever, that would be a huge step forward. First
breaking things for six month or more and then, when the release date
comes nearer, trying to build an upgrade tool is not the right
approach.

A - hopefully not too unrealistic - vision: _At_any_time_ during a
development cycle for release n+1 it is possible to take a cvs
snapshot, build it, take any release n database cluster, run a
conversion script over it (or not), and start the new postmaster with
-D myOldDataDir ...

Granted, this slows down development, primarily while developers are
not yet used to it. But once the infrastructure is in place, things
should get easier. While a developer is working on a new feature he
knows the old data structures as well as the new ones; this is the
best moment to design and implement an upgrade path, which is almost
hopeless if tried several months later by someone else.

And who says that keeping compatibility in mind while developing new
features cannot be fun? I assure you, it is!

Servus
Manfred

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Tom Lane]

Re: State of Beta 2

"Marc G. Fournier" <scrappy@postgr esql.org> writes:[color=blue]
> hmmm ... k, is it feasible to go a release or two at a time without on
> disk changes? if so, pg_upgrade might not be as difficult to maintain,
> since, unless someone an figure out a way of doing it, 'on disk change
> releases' could still require dump/reloads, with a period of stability in
> between?[/color]

Yeah, for the purposes of this discussion I'm just taking "pg_upgrade "
to mean something that does what Bruce's old script does, namely
transfer the schema into the new installation using "pg_dump -s" and
then push the user tables and indexes physically into place. We could
imagine that pg_upgrade would later get some warts added to it to handle
some transformations of the user data, but that might or might not ever
need to happen.

I think we could definitely adopt a policy of "on-disk changes not
oftener than every X releases" if we had a working pg_upgrade, even
without doing any extra work to allow updates. People who didn't
want to wait for the next incompatible release could have their change
sooner if they were willing to do the work to provide an update path.
[color=blue]
> *Or* ... as we've seen more with this dev cycle then previous ones, how
> much could be easily back-patched to the previous version(s) relatively
> easily, without requiring on-disk changes?[/color]

It's very difficult to back-port anything beyond localized bug fixes.
We change the code too much --- for instance, almost no 7.4 patch will
apply exactly to 7.3 or before because of the elog-to-ereport changes.

But the real problem IMHO is we don't have the manpower to do adequate
testing of back-branch changes that would need to be substantially
different from what gets applied to HEAD. I think it's best to leave
that activity to commercial support outfits, rather than put community
resources into it.

(Some might say I have a conflict of interest here, since I work for Red
Hat which is one of said commercial support outfits. But I really do
think it's more reasonable to let those companies do this kind of
gruntwork than to expect the community hackers to do it.)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Manfred Koizar]

Re: State of Beta 2

On Fri, 19 Sep 2003 17:38:13 -0400, Tom Lane <tgl@sss.pgh.pa .us>
wrote:[color=blue][color=green]
>> A working pg_upgrade is *not* the first thing we need.[/color]
>
>Yes it is.[/color]

At the risk of being called a stubborn hairsplitter, I continue to say
that pg_upgrade is not the *first* thing we need. Maybe the second
....
[color=blue]
> As you say later,
>[color=green]
>> ... But once the infrastructure is in place, things
>> should get easier.[/color][/color]

Yes, at some point in time we need an infrastructure/upgrade
process/tool/pg_upgrade, whatever we call it. What I tried to say is
that *first* developers must change their point of view and give
backwards compatibility a higher priority. As long as I don't write
page conversion functions because you changed the system catalogs and
you see no need for pg_upgrade because I broke the page format,
seamless upgrade cannot become a reality.
[color=blue]
>Until we have a working pg_upgrade, every little catalog change will
>break backwards compatibility. And I do not feel that the appropriate
>way to handle catalog changes is to insist on one-off solutions for each
>one.[/color]

I tend to believe that every code change or new feature that gets
implemented is unique by its nature, and if it involves catalog
changes it requires a unique upgrade script/tool. How should a
generic tool guess the contents of a new catalog relation?

Rod's adddepend is a good example. It is a one-off upgrade solution,
which is perfectly adequate because Rod's dependency patch was a
singular work, too. Somebody had to sit down and code some logic into
a script.
[color=blue]
> Any quick look at the CVS logs will show that minor and major
>catalog revisions occur *far* more frequently than changes that would
>affect on-disk representation of user data.[/color]

Some catalog changes can be done by scripts executed by a standalone
backend, others might require more invasive surgery. Do you have any
feeling which kind is the majority?

I've tried to produce a prototype for seamless upgrade with the patch
announced in
http://archives.postgresql.org/pgsql...8/msg00937.php. It
implements new backend functionality (index scan cost estimation using
index correlation) and needs a new system table (pg_indexstat) to
work. I wouldn't call it perfect (for example, I still don't know how
to insert the new table into template0), but at least it shows that
there is a class of problems that require catalog changes and *can* be
solved without initdb.

Servus
Manfred

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Manfred Koizar]

Re: State of Beta 2

On Fri, 19 Sep 2003 18:51:00 -0400, Tom Lane <tgl@sss.pgh.pa .us>
wrote:[color=blue]
>transfer the schema into the new installation using "pg_dump -s" and
>then push the user tables and indexes physically into place.[/color]

I'm more in favour of in-place upgrade. This might seem risky, but I
think we can expect users to backup their PGDATA directory before they
start the upgrade.

I don't trust pg_dump because

.. it doesn't help when the old postmaster binaries are not longer
available

.. it does not always produce scripts that can be loaded without manual
intervention. Sometimes you create a dump and cannot restore it with
the same Postmaster version. RTA.

Servus
Manfred

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postg resql.org so that your
message can get through to the mailing list cleanly

[Manfred Koizar]

Re: State of Beta 2

On Fri, 19 Sep 2003 20:06:39 -0400, Tom Lane <tgl@sss.pgh.pa .us>
wrote:[color=blue]
>Perhaps you should go back and study what
>pg_upgrade actually did.[/color]

Thanks for the friendly invitation. I did that.
[color=blue]
> It needed only minimal assumptions about the
>format of either old or new catalogs. The reason is that it mostly
>relied on portability work done elsewhere (in pg_dump, for example).[/color]

I was hoping that you had a more abstract concept in mind when you
said pg_upgrade; not that particular implementation. I should have
been more explicit that I'm not a friend of that pg_dump approach, cf.
my other mail.
[color=blue][color=green]
>> Rod's adddepend is a good example.[/color]
>I don't think it's representative.[/color]
[color=blue][color=green]
>> ... I wouldn't call it perfect[/color]
>... in other words, it doesn't work and can't be made to work.[/color]

Hmm, "not perfect" == "can't be made to work". Ok. If you want to
see it this way ...

Servus
Manfred

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Marc G. Fournier]

Re: State of Beta 2



On Fri, 19 Sep 2003, Tom Lane wrote:
[color=blue]
> I think we could definitely adopt a policy of "on-disk changes not
> oftener than every X releases" if we had a working pg_upgrade, even
> without doing any extra work to allow updates. People who didn't want
> to wait for the next incompatible release could have their change sooner
> if they were willing to do the work to provide an update path.[/color]

'K, but let's put the horse in front of the cart ... adopt the policy so
that the work on a working pg_upgrade has a chance of succeeding ... if we
said no on disk changes for, let's say, the next release, then that would
provide an incentive (I think!) for someone(s) to pick up the ball and
make sure that pg_upgrade would provide a non-dump/reload upgrade for it
....
[color=blue]
> But the real problem IMHO is we don't have the manpower to do adequate
> testing of back-branch changes that would need to be substantially
> different from what gets applied to HEAD. I think it's best to leave
> that activity to commercial support outfits, rather than put community
> resources into it.[/color]

What would be nice is if we could create a small QA group ...
representative of the various supported platforms, who could be called
upon for testing purposes ... any bugs reported get fixed, its finding the
bugs ...

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Tom Lane]

Re: State of Beta 2

"Marc G. Fournier" <scrappy@postgr esql.org> writes:[color=blue]
> On Fri, 19 Sep 2003, Tom Lane wrote:[color=green]
>> I think we could definitely adopt a policy of "on-disk changes not
>> oftener than every X releases" if we had a working pg_upgrade,[/color][/color]
[color=blue]
> 'K, but let's put the horse in front of the cart ... adopt the policy so
> that the work on a working pg_upgrade has a chance of succeeding ... if we
> said no on disk changes for, let's say, the next release, then that would
> provide an incentive (I think!) for someone(s) to pick up the ball and[/color]

No can do, unless your intent is to force people to work on pg_upgrade
and nothing else (a position I for one would ignore ;-)). With such a
policy and no pg_upgrade we'd be unable to apply any catalog changes at
all, which would pretty much mean that 7.5 would look exactly like 7.4.

If someone wants to work on pg_upgrade, great. But I'm not in favor of
putting all other development on hold until it happens.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to majordomo@postg resql.org)

[Tom Lane]

Re: State of Beta 2

Manfred Koizar <mkoi-pg@aon.at> writes:[color=blue]
> I'm more in favour of in-place upgrade. This might seem risky, but I
> think we can expect users to backup their PGDATA directory before they
> start the upgrade.[/color]
[color=blue]
> I don't trust pg_dump because[/color]

You don't trust pg_dump, but you do trust in-place upgrade? I think
that's backwards.

The good thing about the pg_upgrade process is that if it's gonna fail,
it will fail before any damage has been done to the old installation.
(If we multiply-link user data files instead of moving them, we could
even promise that the old installation is still fully valid at the
completion of the process.) The failure scenarios for in-place upgrade
are way nastier.

As for "expect users to back up in case of trouble", I thought the whole
point here was to make life simpler for people who couldn't afford the
downtime needed for a complete backup. To have a useful backup for an
in-place-upgrade failure, you'd have to run that full backup after
stopping the old postmaster, so you are still looking at long downtime
for an update.
[color=blue]
> it doesn't help when the old postmaster binaries are not longer
> available[/color]

[shrug] This is a matter of design engineering for pg_upgrade. The fact
that we've packaged it in the past as a script that depends on having
the old postmaster executable available is not an indication of how it
ought to be built when we redesign it. Perhaps it should include
back-version executables in it. Or not; but clearly it has to be built
with an understanding of what the total upgrade process would look like.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Marc G. Fournier]

Re: State of Beta 2



On Sat, 20 Sep 2003, Tom Lane wrote:
[color=blue]
> "Marc G. Fournier" <scrappy@postgr esql.org> writes:[color=green]
> > On Fri, 19 Sep 2003, Tom Lane wrote:[color=darkred]
> >> I think we could definitely adopt a policy of "on-disk changes not
> >> oftener than every X releases" if we had a working pg_upgrade,[/color][/color]
>[color=green]
> > 'K, but let's put the horse in front of the cart ... adopt the policy so
> > that the work on a working pg_upgrade has a chance of succeeding ... if we
> > said no on disk changes for, let's say, the next release, then that would
> > provide an incentive (I think!) for someone(s) to pick up the ball and[/color]
>
> No can do, unless your intent is to force people to work on pg_upgrade
> and nothing else (a position I for one would ignore ;-)). With such a
> policy and no pg_upgrade we'd be unable to apply any catalog changes at
> all, which would pretty much mean that 7.5 would look exactly like 7.4.[/color]

No, I'm not suggesting no catalog changes ... wait, I might be wording
this wrong ... there are two changes that right now requires a
dump/reload, changes to the catalogs and changes to the data structures,
no? Or are these effectively inter-related?

If they aren't inter-related, what I'm proposing is to hold off on any
data structure changes, but still make catalog changes ... *if*, between
v7.4 and v7.5, nobody can bring pg_upgrade up to speed to be able to
handle the catalog changes without a dump/reload, then v7.5 will require
one ... but, at least it would give a single 'moving target' for the
pg_upgrade development to work on, instead of two ...

Make better sense?


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Joshua D. Drake]

Re: State of Beta 2

[color=blue][color=green]
>>I don't trust pg_dump because
>>
>>[/color]
>
>You don't trust pg_dump, but you do trust in-place upgrade? I think
>that's backwards.
>[/color]
Well to be honest. I have personally had nightmares of problems with
pg_dump. In fact I have
a large production database right now that can't use it to restore
because of the way pg_dump
handles large objects. So I can kind of see his point here. I had to
move to a rsync based backup/restore system.

The reality of pg_dump is not a good one. It is buggy and not very
reliable. This I am hoping
changes in 7.4 as we moved to a pure "c" implementation.

But I do not argue any of the other points you make below.

Sincerely,

Joshua Drake
[color=blue]
>The good thing about the pg_upgrade process is that if it's gonna fail,
>it will fail before any damage has been done to the old installation.
>(If we multiply-link user data files instead of moving them, we could
>even promise that the old installation is still fully valid at the
>completion of the process.) The failure scenarios for in-place upgrade
>are way nastier.
>
>As for "expect users to back up in case of trouble", I thought the whole
>point here was to make life simpler for people who couldn't afford the
>downtime needed for a complete backup. To have a useful backup for an
>in-place-upgrade failure, you'd have to run that full backup after
>stopping the old postmaster, so you are still looking at long downtime
>for an update.
>
>
>[color=green]
>>it doesn't help when the old postmaster binaries are not longer
>>available
>>
>>[/color]
>
>[shrug] This is a matter of design engineering for pg_upgrade. The fact
>that we've packaged it in the past as a script that depends on having
>the old postmaster executable available is not an indication of how it
>ought to be built when we redesign it. Perhaps it should include
>back-version executables in it. Or not; but clearly it has to be built
>with an understanding of what the total upgrade process would look like.
>
> regards, tom lane
>
>[/color]



---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddres sHere" to majordomo@postg resql.org)

[Tom Lane]

Re: State of Beta 2

"Marc G. Fournier" <scrappy@postgr esql.org> writes:[color=blue]
> No, I'm not suggesting no catalog changes ... wait, I might be wording
> this wrong ... there are two changes that right now requires a
> dump/reload, changes to the catalogs and changes to the data structures,
> no? Or are these effectively inter-related?[/color]

Oh, what you're saying is no changes in user table format. Yeah, we
could probably commit to that now. Offhand the only thing I think it
would hold up is the one idea about converting "interval" into a
three-component value, and I'm not sure if anyone had really committed
to work on that anyway ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postg resql.org

[Dennis Gearon]

Re: State of Beta 2

You know, I can't help but thinking that there are a NUMBER of major
items on the TO DO list, this one, and several others that are related.
The point made that future clients and backends can't talk to old tables
is a good one. I used to rant and rave about Microslop doing that every
third or fourth version, and Postgres does it every minor revision. Hmmmm.

Is there a ROADMAP of integrated todo's somewhere?

Marc G. Fournier wrote:
[color=blue]
>On Thu, 18 Sep 2003, Lamar Owen wrote:
>
>
>[color=green][color=darkred]
>>>Huh? I have no disagreement that upgrading is a key feature that we are
>>>lacking ... but, if there are any *on disk* changes between releases, how
>>>do you propose 'in place upgrades'?
>>>
>>>[/color]
>>RTA. It's been hashed, rehashed, and hashed again. I've asked twice if
>>eRserver can replicate a 7.3 database onto a 7.4 server (or a 7.2 onto a
>>7.3); that question has yet to be answered.
>>
>>[/color]
>
>'K, I had already answered it as part of this thread when I suggested
>doing exactly that ... in response to which several ppl questioned the
>feasibility of setting up a duplicate system with >1TB of disk space to do
>the replication over to ...
>
>See: http://archives.postgresql.org/pgsql...9/msg00886.php
>
>
>[/color]


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

[Lamar Owen]

Re: State of Beta 2

Marc G. Fournier wrote:[color=blue]
> 'K, I had already answered it as part of this thread when I suggested
> doing exactly that ... in response to which several ppl questioned the
> feasibility of setting up a duplicate system with >1TB of disk space to do
> the replication over to ...[/color]

The quote mentioned is a question, not an answer. You said:[color=blue]
> 'k, but is it out of the question to pick up a duplicate server, and use
> something like eRServer to replicate the databases between the two
> systems, with the new system having the upgraded database version running
> on it, and then cutting over once its all in sync?[/color]

'Something like eRserver' doesn't give me enough detail; so I asked if
eRserver could do this, mentioning specific version numbers. A straight
answer -- yes it can, or no it can't -- would be nice. So you're saying
that eRserver can do this, right? Now if there just wasn't that java
dependency.... Although the contrib rserv might suffice for data
migration capabilities.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute



---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Joshua D. Drake]

Re: State of Beta (2)

Hello,

Sure this is all reasonable but would come after the initial 30 days.
The first 30 days is specifically a proof of concept,
validitity study, review of findings type of thing. Which is why I
stated that we would produce the findings and our project
plan to proceed after the initial 30 days.

Sincerely,

Joshua Drake



Network Administrator wrote:
[color=blue]
>That sounds good save two things. We need to state what are the project run
>dates and what happens at or around the due date. That to say we have the
>deliverable for testing (beta ready), more time is needed to complete core
>features (alpha ready) and therefore more funds are needed, project is one hold
>due to features needed outside the scope of the project, etc, etc, etc...
>
>You get the idea.
>
>Quoting "Joshua D. Drake" <jd@commandprom pt.com>:
>
>
>[color=green]
>>Hello,
>>
>> O.k. here are my thoughts on how this could work:
>>
>> Command Prompt will set up an escrow account online at www.escrow.com.
>> When the Escrow account totals 2000.00 and is released, Command Prompt
>>will dedicate a
>> programmer for one month to debugging, documenting, reviewing,
>>digging, crying,
>> screaming, begging and bleeding with the code. At the end of the month
>>and probably during
>> depending on how everything goes Command Prompt will release its
>>findings. The findings
>> will include a project plan on moving forward over the next 5 months
>>(if that is what it takes) to
>> produce the first functional pg_upgrade.
>>
>> If the project is deemed as moving in the right direction by the
>>community members and specifically
>> the core members we will setup milestone payments for the project.
>>
>> What does everyone think?
>>
>> Sincerely,
>>
>> Joshua D. Drake
>>
>>
>>Dennis Gearon wrote:
>>
>>
>>[color=darkred]
>>>I had already committed $50/mo.
>>>
>>>Robert Creager wrote:
>>>
>>>
>>>
>>>>Once upon a time (Tue, 16 Sep 2003 21:26:05 -0700)
>>>>Dennis Gearon <gearond@firese rve.net> uttered something amazingly
>>>>similar to:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Robert Creager wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Once upon a time (Tue, 16 Sep 2003 12:59:37 -0700)
>>>>>>"Joshua D. Drake" <jd@commandprom pt.com> uttered something
>>>>>>amazing ly similar
>>>>>>to:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>If someone is willing to pony up 2000.00 per month for a period of
>>>>>>>at
>>>>>>>
>>>>>>>
>>>>>>Well, if you're willing to set up some sort of escrow, I'll put in
>>>>>>$100. I
>>>>>>
>>>>>>
>>>>>>
>>>>>Is that $100 times once, or $100 X 6mos anticiapated develop time.
>>>>>
>>>>>
>>>>>
>>>>That's $100 once. And last I looked, there are well over 1800
>>>>subscribe rs on
>>>>this list alone. On the astronomically small chance everyone one of
>>>>them did
>>>>what I'm doing, it would cover more than 6 months of development time
>>>>;-) This
>>>>strikes me as like supporting public radio. The individuals do some,
>>>>and the
>>>>corporation s do a bunch.
>>>>
>>>>I'm just putting my money toward a great product, rather than
>>>>complaini ng that
>>>>it's not done. Just like Joshua is doing. You cannot hire a competent
>>>>programme r for $24k a year, so he is putting up some money on this also.
>>>>
>>>>There have been a couple of other bytes from small businesses, so who
>>>>knows!
>>>>
>>>>You game?
>>>>
>>>>Cheers,
>>>>Rob
>>>>
>>>>
>>>>
>>>>
>>>>[/color]
>>--
>>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@commandpromp t.com - http://www.commandprompt.com
>>The most reliable support for the most reliable Open Source database.
>>
>>
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 5: Have you checked our extensive FAQ?
>>
>> http://www.postgresql.org/docs/faqs/FAQ.html
>>
>>
>>[/color]
>
>
>
>[/color]

--
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@commandpromp t.com - http://www.commandprompt.com
The most reliable support for the most reliable Open Source database.



---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postg resql.org