Re: State of Beta 2 - Mailing list pgsql-general
From | Lamar Owen |
---|---|
Subject | Re: State of Beta 2 |
Date | |
Msg-id | 3F6715BB.4040107@pari.edu Whole thread Raw |
In response to | Re: State of Beta 2 ("Marc G. Fournier" <scrappy@postgresql.org>) |
Responses |
Re: State of Beta 2
Re: State of Beta 2 Re: State of Beta 2 Re: State of Beta 2 |
List | pgsql-general |
Marc G. Fournier wrote: > On Mon, 15 Sep 2003, Joshua D. Drake wrote: >>>I'm not going to rehash the arguments I have made before; >>I at no point suggested that there was not a need. I only suggest that >>the need may not be as great as some suspect or feel. To be honest -- if >>your arguments were the "need" that everyone had... it would have been >>implemented some how. It hasn't yet which would suggest that the number > Just to add to this ... Bruce *did* start pg_upgrade, but I don't recall > anyone else looking at extending it ... if the *need* was so great, > someone would have step'd up and looked into adding to what was already > there ... You'ns are going to make a liar out of me yet; I said I wasn't going to rehash the arguments. But I am going to answer Marc's statement. Need of the users != developer interest in implementing those. This is the ugly fact of open source software -- it is developer-driven, not user-driven. If it were user-driven in this case seamless upgrading would have already happened. But the sad fact is that the people who have the necessary knowledge of the codebase in question are so complacent and comfortable with the current dump/reload cycle that they really don't seem to care about the upgrade issue. That is quite a harsh statement to make, yes, and I know that is kind of uncharacteristic for me. But, Marc, your statement thoroughy ignores the archived history of this issue on the lists. While pg_upgrade was a good first step (and I applaud Bruce for working on it), it was promptly broken because the developers who changed the on-disk format felt it wasn't important to make it continue working. Stepping up to the plate on this issue will require an intimate knowledge of the storage manager subsystem, a thorough knowledge of the system catalogs, etc. This has been discussed at length; I'll not repeat it. Just any old developer can't do this -- it needs the long-term focused attention of Tom, Jan, or Bruce. And that isn't going to happen. We know Tom's take on it; it's archived. Maybe there's someone out there with the deep knowledge of the backend to make this happen who cares enough about it to make it happen, and who has the time to do it. I care enough to do the work; but I have neither the deep knowledge necessary nor the time to make it happen. There are many in my position. But those who could make it happen don't seem to have the care level to do so. And that has nothing to do with user need as a whole, since the care level I mentioned is predicated by the developer interest level. While I know, Marc, how the whole project got started (I have read the first posts), and I appreciate that you, Bruce, Thomas, and Vadim started the original core team because you were and are users of PostgreSQL, I sincerely believe that in this instance you are out of touch with this need of many of today's userbase. And I say that with full knowledge of PostgreSQL Inc.'s support role. If given the choice between upgrading capability, PITR, and Win32 support, my vote would go to upgrading. Then migrating to PITR won't be a PITN. What good are great features if it's a PITN to get upgraded to them? -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute
pgsql-general by date: