Thread: Re: Call for 7.5 feature completion
Bruce Momjian wrote: > Yes, it was vague. The question is now that we are a month away, do we > want to target June 1, mid-June, or July 1. If I may humbly chime in here...there currently is no binary packing for the win32 port. Magnus is currently working on an installer/service manager (dubbed 'longer term' on the status page) that would be nice to see make it in before the feature freeze. Based on the current rate of development, finishing this and various other sundry issues (even allowing for corrections within the beta period) within a month involves a fair degree of optimism. In short, speaking strictly from a win32 perspective, a June 1 date will probably be missed. Merlin
Merlin Moncure wrote: > Bruce Momjian wrote: > > Yes, it was vague. The question is now that we are a month away, do > we > > want to target June 1, mid-June, or July 1. > > If I may humbly chime in here...there currently is no binary packing for > the win32 port. Magnus is currently working on an installer/service > manager (dubbed 'longer term' on the status page) that would be nice to > see make it in before the feature freeze. Based on the current rate of > development, finishing this and various other sundry issues (even > allowing for corrections within the beta period) within a month involves > a fair degree of optimism. In short, speaking strictly from a win32 > perspective, a June 1 date will probably be missed. Well, if Win32 doesn't complete by June 1, do we still do the feature freeze? I don't want to be adding features after the freeze, that is for sure. When we have done that in the past, it has caused problems because some stuff gets in to make the system unstable, but other stuff gets left out. As I remember, we decided that we should not make decisions to extend the feature freeze date just before the freeze date because it causes people to stop doing development, then we extend. I think we should go another week or two then decide if we should stay to June 1, and if we don't, we should schedule for July 1. Extending it by a week at a time, and almost before the deadline, has caused considerable waste of time in the past. -- 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, Pennsylvania19073
"Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
> Bruce Momjian wrote:
>> Yes, it was vague. The question is now that we are a month away, do
>> we want to target June 1, mid-June, or July 1.
> ... In short, speaking strictly from a win32
> perspective, a June 1 date will probably be missed.
Fair enough. Do you feel comfortable with either of the other dates?
The point of this discussion is not so much to crack the whip as to get
people's schedule expectations aligned. If we set a date X, those who
can't possibly meet it will know to plan on getting into a later release
instead, and those who can meet it if they hustle will know to start
hustling. But we need to set a date. It's unfair to other parts of the
project to say "oh, we'll wait till Win32 is ready and then give two
weeks notice".
regards, tom lane
Bruce Momjian wrote: > Well, if Win32 doesn't complete by June 1, do we still do the feature > freeze? I don't want to be adding features after the freeze, that is > for sure. When we have done that in the past, it has caused problems > because some stuff gets in to make the system unstable, but other stuff > gets left out. It seams as though the win32 port is driving the release schedule, so instead of picking June 1 out of the air, how about getting an estimated time for completion from them, or more specifically a date by which they should have all the major features done? I know it's a chicken and egg problem, do we set a date for developers to shoot for, or do shoot for specific features and choose a date from there. I think there can no hard and fast rule on this, it depends on the feature and the desire to put it in place. Matthew
Tom Lane wrote: > "Merlin Moncure" <merlin.moncure@rcsonline.com> writes: > > Bruce Momjian wrote: > >> Yes, it was vague. The question is now that we are a month away, do > >> we want to target June 1, mid-June, or July 1. > > > ... In short, speaking strictly from a win32 > > perspective, a June 1 date will probably be missed. > > Fair enough. Do you feel comfortable with either of the other dates? > > The point of this discussion is not so much to crack the whip as to get > people's schedule expectations aligned. If we set a date X, those who > can't possibly meet it will know to plan on getting into a later release > instead, and those who can meet it if they hustle will know to start > hustling. But we need to set a date. It's unfair to other parts of the > project to say "oh, we'll wait till Win32 is ready and then give two > weeks notice". Well, looking at Win32, we are making steady progress, but it is uncertain if we will make June 1, and we might not know even on May 15 if we will make that date, and if we don't know we have to either stick to June 1 and ignore Win32 or extend to July 1. We can't decide on May 29 because then all the other features are left hanging to see what happens with Win32. I wonder if we should just pick July 1 because there is good expectation based on current progress that Win32 will be done by June 15, which would be the next cuttoff date. Of course we can wait until May 15 and then decide. -- 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, Pennsylvania19073
Matthew T. O'Connor wrote: > Bruce Momjian wrote: > > Well, if Win32 doesn't complete by June 1, do we still do the feature > > freeze? I don't want to be adding features after the freeze, that is > > for sure. When we have done that in the past, it has caused problems > > because some stuff gets in to make the system unstable, but other stuff > > gets left out. > > > It seams as though the win32 port is driving the release schedule, so > instead of picking June 1 out of the air, how about getting an estimated > time for completion from them, or more specifically a date by which they > should have all the major features done? I just posted on this. I am putting timezone in today, but we have fsync to do, and some other stuff. Might be done in two weeks, but most likely it will take 4. -- 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, Pennsylvania19073
Bruce Momjian wrote: > Well, if Win32 doesn't complete by June 1, do we still do the feature > freeze? I don't want to be adding features after the freeze, that is [...] > As I remember, we decided that we should not make decisions to extend > the feature freeze date just before the freeze date because it causes > people to stop doing development, then we extend. I think we should go > another week or two then decide if we should stay to June 1, and if we > don't, we should schedule for July 1. Extending it by a week at a time, > and almost before the deadline, has caused considerable waste of time in > the past. I agree 100%. Right now the win32 side doesn't qualify for beta...just the date issue alone is a pretty big deal, IMO. There are pending patches for only about 50% of the outstanding issues. A tremendous amount of work has been done, but there is still quite a bit to be done to meet basic QC guidelines. So I suggest (my choices are of course subjective): Dividing win32 'should fix' (installer, /contrib, etc.) win32 'must fix' (psql query cancel, <1970 dates, non-cygwin regression) Apply freeze date to the 'must fix' items. 'Should fix' items can be delayed until the beta, dot release, or beyond. My personal estimation on completion date depends on what gets put in which category. If everything is designated 'must fix', I think July 1 is practical. Merlin
On Thu, 29 Apr 2004, Bruce Momjian wrote: > Merlin Moncure wrote: > > Bruce Momjian wrote: > > > Yes, it was vague. The question is now that we are a month away, do > > we > > > want to target June 1, mid-June, or July 1. > > > > If I may humbly chime in here...there currently is no binary packing for > > the win32 port. Magnus is currently working on an installer/service > > manager (dubbed 'longer term' on the status page) that would be nice to > > see make it in before the feature freeze. Based on the current rate of > > development, finishing this and various other sundry issues (even > > allowing for corrections within the beta period) within a month involves > > a fair degree of optimism. In short, speaking strictly from a win32 > > perspective, a June 1 date will probably be missed. > > Well, if Win32 doesn't complete by June 1, do we still do the feature > freeze? I don't want to be adding features after the freeze, that is > for sure. When we have done that in the past, it has caused problems > because some stuff gets in to make the system unstable, but other stuff > gets left out. That is something that should be discussed a couple of days before June 1st, when we have a clearer idea of just how far off Win32 will be ... right now, if Win32 is *that* far off the June 1st mark, I'd say definitely to a feature freeze, as much as I'd like to see the Win32 features in ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Thu, 29 Apr 2004, Matthew T. O'Connor wrote: > I know it's a chicken and egg problem, do we set a date for developers > to shoot for, or do shoot for specific features and choose a date from > there. I think there can no hard and fast rule on this, it depends on > the feature and the desire to put it in place. If we set the date based on a specific featuer, v7.4 would still be in development ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Thu, 29 Apr 2004, Bruce Momjian wrote: > I wonder if we should just pick July 1 because there is good expectation > based on current progress that Win32 will be done by June 15, which > would be the next cuttoff date. Of course we can wait until May 15 and > then decide. Start of summer holidays, when most ppl will want to be away? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
> -----Original Message----- > From: Merlin Moncure [mailto:merlin.moncure@rcsonline.com] > Sent: Thursday, April 29, 2004 12:45 PM > To: Bruce Momjian > Cc: pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Call for 7.5 feature completion > > > Bruce Momjian wrote: > > Well, if Win32 doesn't complete by June 1, do we still do > the feature > > freeze? I don't want to be adding features after the > freeze, that is > [...] > > As I remember, we decided that we should not make decisions > to extend > > the feature freeze date just before the freeze date because > it causes > > people to stop doing development, then we extend. I think we should > go > > another week or two then decide if we should stay to June > 1, and if we > > don't, we should schedule for July 1. Extending it by a week at a > time, > > and almost before the deadline, has caused considerable > waste of time > in > > the past. > > I agree 100%. Right now the win32 side doesn't qualify for > beta...just the date issue alone is a pretty big deal, IMO. > There are pending > patches for only about 50% of the outstanding issues. A tremendous > amount of work has been done, but there is still quite a bit > to be done to meet basic QC guidelines. > > So I suggest (my choices are of course subjective): > Dividing > win32 'should fix' (installer, /contrib, etc.) > win32 'must fix' (psql query cancel, <1970 dates, non-cygwin > regression) About the date/time stuff. We (of course) had the exact same issues with dates and times when we did a native port of 7.1.3. Since we want to represent dates and times with exactness of nanoseconds from thousands of years BC up to thousands of years in the future, it was a major piece of work. The code base is not titanically large, but it was pretty tricky getting it right. First the bad news: There is no native data type in the C lanaguage that can store with the required precision so we used Moshier's Qfloat. With PostgreSQL, perhaps the intermediate values could be stored in numeric type instead. Now the worse news: Everything is in C++ and represented as objects Maybe it would not be too hard to translate the algorithms into C, since the languages are fairly similar. > Apply freeze date to the 'must fix' items. 'Should fix' > items can be delayed until the beta, dot release, or beyond. > My personal estimation on completion date depends on what > gets put in which category. If everything is designated > 'must fix', I think July 1 is practical.
On Thu, 29 Apr 2004, Merlin Moncure wrote: > Bruce Momjian wrote: > > Well, if Win32 doesn't complete by June 1, do we still do the feature > > freeze? I don't want to be adding features after the freeze, that is > [...] > > As I remember, we decided that we should not make decisions to extend > > the feature freeze date just before the freeze date because it causes > > people to stop doing development, then we extend. I think we should > go > > another week or two then decide if we should stay to June 1, and if we > > don't, we should schedule for July 1. Extending it by a week at a > time, > > and almost before the deadline, has caused considerable waste of time > in > > the past. > > I agree 100%. Right now the win32 side doesn't qualify for beta...just > the date issue alone is a pretty big deal, IMO. There are pending > patches for only about 50% of the outstanding issues. A tremendous > amount of work has been done, but there is still quite a bit to be done > to meet basic QC guidelines. > > So I suggest (my choices are of course subjective): > Dividing > win32 'should fix' (installer, /contrib, etc.) > win32 'must fix' (psql query cancel, <1970 dates, non-cygwin regression) actually, IMHO, some of these should be classified as bug fixes, assuming that the patches are already in the source tree, and don't affect the feature freeze in any way, only the release ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Thu, 29 Apr 2004, Simon Riggs wrote: > What I would add is: if PITR and Win32 do make it into the release, I > would strongly urge for an extended beta period. It would not prove good > press if 100,000 new Windows users tripped over on various issues, nor > even 1 press-worthy user was unable to recover correctly. Granted ... our beta periods always tend to be as long as required to be confident of stability ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Thu, 2004-04-29 at 20:50, Marc G. Fournier wrote: > On Thu, 29 Apr 2004, Bruce Momjian wrote: > > > Merlin Moncure wrote: > > > Bruce Momjian wrote: > > > > Yes, it was vague. The question is now that we are a month away, do > > > we > > > > want to target June 1, mid-June, or July 1. > > > > > > If I may humbly chime in here...there currently is no binary packing for > > > the win32 port. Magnus is currently working on an installer/service > > > manager (dubbed 'longer term' on the status page) that would be nice to > > > see make it in before the feature freeze. Based on the current rate of > > > development, finishing this and various other sundry issues (even > > > allowing for corrections within the beta period) within a month involves > > > a fair degree of optimism. In short, speaking strictly from a win32 > > > perspective, a June 1 date will probably be missed. > > > > Well, if Win32 doesn't complete by June 1, do we still do the feature > > freeze? I don't want to be adding features after the freeze, that is > > for sure. When we have done that in the past, it has caused problems > > because some stuff gets in to make the system unstable, but other stuff > > gets left out. > > That is something that should be discussed a couple of days before June > 1st, when we have a clearer idea of just how far off Win32 will be ... > right now, if Win32 is *that* far off the June 1st mark, I'd say > definitely to a feature freeze, as much as I'd like to see the Win32 > features in ... Completely agree - I've been working to that timescale since March. This is probably the determining factor as to whether the release number is 7.5 or 8.0? What I would add is: if PITR and Win32 do make it into the release, I would strongly urge for an extended beta period. It would not prove good press if 100,000 new Windows users tripped over on various issues, nor even 1 press-worthy user was unable to recover correctly. Best Regards, Simon Riggs
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> On Thu, 29 Apr 2004, Merlin Moncure wrote:
>> So I suggest (my choices are of course subjective):
>> Dividing
>> win32 'should fix' (installer, /contrib, etc.)
>> win32 'must fix' (psql query cancel, <1970 dates, non-cygwin regression)
> actually, IMHO, some of these should be classified as bug fixes, assuming
> that the patches are already in the source tree, and don't affect the
> feature freeze in any way, only the release ...
The issue is really whether the "bug fixes" are major enough to
invalidate any previous beta testing. For example, it would be
unreasonable to go beta with the "<1970 dates" issue unresolved, because
what we are talking about doing to fix that involves plopping in a
pretty big chunk of new (to us anyway) code. And since we plan to use
that code on all platforms, it needs beta testing everywhere. Another
example is the sync/fsync changes we are talking about making --- that's
pretty basic and it'll need QA on all platforms not just win32.
It would be reasonable to go beta with open minor issues that we
expect to be fixable by localized patches. (But on the other hand,
why wouldn't such issues be resolved before then?)
So I'm not sure that "should fix vs must fix" is the appropriate
classification. "Small/localized fix vs nontrivial change"
is more what I'm worried about.
regards, tom lane
> The other point, especially about Win32, is to see if we can > spread the load a bit. Perhaps Claudio, Magnus, Merlin and Bruce > should start trying to farm out specific tasks. Here are the tasks, off the Win32 page, I see as necessary to drop in: * Handle sync() by opening all file opened since the last fsync and fsync'ing those- Tom's got this one, as is the most crucial outstanding part * changes to replace PGBINDIR, PGDATADIR (as per PKGLIBDIR)- I'm waiting for a reply from Tom/Peter for suggestions, as objectors to a previous patch * locatime under Win32 with pre-1970 dates- Magnus has submitted; Bruce will commit any time now * Win32 installer- I believe Magnus already has something in this regard * Win32 service- Rony offered to do this, but have not heard back. Not a major item, and I've already got an implementation from my previous port. * Fix problem were locale doesn't match host locale, requires passing more params to startup applications- SMOP All other issues are nicities or fixups, IMHO. There really isn't anything that needs farming out, just a matter of having the pieces fall into place. > I for one will be very upset if it misses this release. If I have anything to do with it, this won't happen. I'll do whatever I can to make the release. That's my 2c. I don't see anything that can't make a June 1 deadline (assuming we are expected to keep to it! :-)... the only unknown for me is the sync/fsync code Tom is doing, only as I have no idea where he is up to. I've been AWOL for a month, but will again start actively contributing, but as things stand there isn't a great deal left to do to take Win32 to beta. Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see <a href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em ailpolicy.html</a>
> > Win32 has continued on a steady pace for six months now. > > Be honest ... 6 months ago, did you believe the Win32 work would have > taken >6 months? How many of the current issues could you have > anticipated? How many will crop up in the next month? FWIW, the backend porting effort started less than 5 months ago :-P What "current issues" are there? The only ones of any significance that popped up were the APC/socket interactions and the localtime deficiencies, both of which now appear solved. Perhaps I will regret saying this but from my point of view, apart from the fsync/sync code Tom is working on that I am in complete ignorance of, I do not imagine any new issues in the remaining items required to get win32 to beta. Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see <a href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em ailpolicy.html</a>
Claudio Natoli wrote: > > > > > Win32 has continued on a steady pace for six months now. > > > > Be honest ... 6 months ago, did you believe the Win32 work would have > > taken >6 months? How many of the current issues could you have > > anticipated? How many will crop up in the next month? > > FWIW, the backend porting effort started less than 5 months ago :-P > > What "current issues" are there? The only ones of any significance that > popped up were the APC/socket interactions and the localtime deficiencies, > both of which now appear solved. > > Perhaps I will regret saying this but from my point of view, apart from the > fsync/sync code Tom is working on that I am in complete ignorance of, I do > not imagine any new issues in the remaining items required to get win32 to > beta. Agreed. My major issue is that we don't have enough _big_ items completed to set a feature freeze date. I think we need X big items completed before we can push for 7.5, even forgetting Win32. I know we did a lot already, but we need some big splash items for 7.5. These are being worked on, and if it takes X months to get them, it takes X months. Once we have X features working, we can look for a feature freeze. Maybe those features will not even include Win32 (though I would be surprised). -- 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, Pennsylvania19073
Claudio Natoli <claudio.natoli@memetrics.com> writes:
> That's my 2c. I don't see anything that can't make a June 1 deadline
> (assuming we are expected to keep to it! :-)... the only unknown for me is
> the sync/fsync code Tom is doing, only as I have no idea where he is up to.
> I've been AWOL for a month, but will again start actively contributing, but
> as things stand there isn't a great deal left to do to take Win32 to beta.
I am willing to commit to making the fsync thing happen by June 1. If
you are confident that everything else can be fixed by then, my vote is
to hold to the June 1 schedule. (I was just panicking because some
other folk didn't think everything else could get done...)
regards, tom lane
Marc G. Fournier wrote: >On Thu, 29 Apr 2004, Matthew T. O'Connor wrote: > > >>I know it's a chicken and egg problem, do we set a date for developers >>to shoot for, or do shoot for specific features and choose a date from >>there. I think there can no hard and fast rule on this, it depends on >>the feature and the desire to put it in place. >> >> > >If we set the date based on a specific featuer, v7.4 would still be in >development ... > > > And if we always set deadlines independent of the required development time, then we may never get a win32 port or any other major feature that takes a little more time and attention.
On Fri, 30 Apr 2004, Matthew T. O'Connor wrote: > And if we always set deadlines independent of the required development > time, then we may never get a win32 port or any other major feature that > takes a little more time and attention. Actually, that one doesn't hold ... it just means that we need to mature our development environments to match the larger projects that need to happen ... we are using CVS, there is nothing that stops a side-branch being started, like we did with the Win32 stuff and then merging it back up when the feature is ready .. ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
> > Yes, it was vague. The question is now that we are a month away, do > we > > want to target June 1, mid-June, or July 1. > > If I may humbly chime in here...there currently is no binary > packing for the win32 port. Magnus is currently working on > an installer/service manager (dubbed 'longer term' on the > status page) that would be nice to see make it in before the > feature freeze. Just a clearification here - I am only working on the installer. *Not* on the service manager integration code. That one is flagged for Rony, or Claudio has some code almost ready. I haven't touched that part. //Magnus
> * Handle sync() by opening all file opened since the last > fsync and fsync'ing those > - Tom's got this one, as is the most crucial outstanding part Yes, this is defintly the largest part of the code missing. > * Win32 installer > - I believe Magnus already has something in this regard Yup. I'll try to clean it up a bit and post it soon. A question about this though - do we want the installer source (required to build the MSI - not the MSI itself, of course) in main CVS? I asked before how it's handled for RPMs etc, and had no response there (it was probably a bit too much inside other discussions). If it shuold not be included in the main code (say, on gborg instead), it really shouldn't hold up going beta on the main backend. Thoughts? > * Win32 service > - Rony offered to do this, but have not heard back. Not > a major item, and I've already got an implementation from my > previous port. Whomever does this in the end, it should not be a lot of code, and not very complicated. There are a zillion examples all over on code that does this (for example the SDK samples from MS), and it's not complicated stuff. > * Fix problem were locale doesn't match host locale, requires > passing more params to startup applications > - SMOP I'm looking into a quick-fix (but not as quick as the hack I did earlier). If it's not too much work, expect it fairly shortly. The "good looking" fix will come out of the backend startup reorganisation/cleanup Claudio will eventually do :-) The stuff I'm looking at should not be more ugly than what's there now, but there was agreement that what's there now is a bit more complicated than necessary. > All other issues are nicities or fixups, IMHO. There really > isn't anything that needs farming out, just a matter of > having the pieces fall into place. Agreed. //Magnus
Am Freitag, 30. April 2004 12:45 schrieb Magnus Hagander: > A question about this though - do we want the installer source (required > to build the MSI - not the MSI itself, of course) in main CVS? We don't have any other packaging-related files in our CVS (for various good reasons), so I don't think the Windows installer should be in there.
On Fri, 30 Apr 2004, Peter Eisentraut wrote: > Am Freitag, 30. April 2004 12:45 schrieb Magnus Hagander: > > A question about this though - do we want the installer source (required > > to build the MSI - not the MSI itself, of course) in main CVS? > > We don't have any other packaging-related files in our CVS (for various good > reasons), so I don't think the Windows installer should be in there. Agreed ... put it as a project on PgFoundry ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: >On Fri, 30 Apr 2004, Peter Eisentraut wrote: > > > >>Am Freitag, 30. April 2004 12:45 schrieb Magnus Hagander: >> >> >>>A question about this though - do we want the installer source (required >>>to build the MSI - not the MSI itself, of course) in main CVS? >>> >>> >>We don't have any other packaging-related files in our CVS (for various good >>reasons), so I don't think the Windows installer should be in there. >> >> > >Agreed ... put it as a project on PgFoundry ... > > > > That will also be a sensible place to publish RC Binary packages for people to test. cheers andrew
> It is too late to think about pushing back another month. We had this > discussion already. June 1 is it. I thought the outcome of that discussion was June 15 ? Can we try to do the 2PC patch now instead of waiting for subtransactions ? Andreas
On Mon, May 17, 2004 at 04:55:50PM +0200, Zeugswetter Andreas SB SD wrote: > > > It is too late to think about pushing back another month. We had this > > discussion already. June 1 is it. > > I thought the outcome of that discussion was June 15 ? I think there was no outcome. There was no official pronouncement, there was no vote, there was no consensus. People seemed to stick with whatever was closer. > Can we try to do the 2PC patch now instead of waiting for subtransactions ? The last post from Heikki I read said that he discovered some serious problems with his implementation and he wanted do rethink about them. I don't think he will be able to make it, mainly because if my patch gets accepted it will be too close to feature freeze (if it is June 1st). Personally I've been focused on getting subtransactions done and now I think I'm very close to an acceptable patch, but what has slowed me down the last time has been lack of feedback from core developers. It was feedback I needed to figure out the best ways to do things (I made several big mistakes that I'm only now correcting thanks to invaluable comments from Tom Lane), and without it the last steps were getting very difficult to me. Fortunately now I've got it. I have some confidence in that I will be able to deliver it maybe the last week of May. I can only hope, however, that it will not be rejected because it's presented too close to feature freeze. That would be a shame, because I offered incremental patches a lot of time ago and they weren't even looked at (Hey, I'm not blaming anyone). -- Alvaro Herrera (<alvherre[@]dcc.uchile.cl>) FOO MANE PADME HUM
Alvaro Herrera Munoz wrote: > Personally I've been focused on getting subtransactions done and now I think > I'm very close to an acceptable patch, but what has slowed me down the last > time has been lack of feedback from core developers. It was feedback I > needed to figure out the best ways to do things (I made several big mistakes > that I'm only now correcting thanks to invaluable comments from Tom Lane), > and without it the last steps were getting very difficult to me. > Fortunately now I've got it. > > I have some confidence in that I will be able to deliver it maybe the last > week of May. I can only hope, however, that it will not be rejected because > it's presented too close to feature freeze. That would be a shame, because > I offered incremental patches a lot of time ago and they weren't even looked > at (Hey, I'm not blaming anyone). One huge problem is that many features are asking for our attention this close to freeze date. I spend some time on relative-path installs, and now there are lots of patches that need to be reviewed and placed into the queue, and we haven't been giving you enough feedback. And I am thinking of helping with PITR because there isn't much work to do except plugging into the backend and GUC. -- 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, Pennsylvania19073
On Mon, 17 May 2004, Alvaro Herrera Munoz wrote: > On Mon, May 17, 2004 at 04:55:50PM +0200, Zeugswetter Andreas SB SD wrote: > > Can we try to do the 2PC patch now instead of waiting for subtransactions ? > > The last post from Heikki I read said that he discovered some serious > problems with his implementation and he wanted do rethink about them. I > don't think he will be able to make it, mainly because if my patch gets > accepted it will be too close to feature freeze (if it is June 1st). That's still the status with my 2PC patch. It works, as long as you don't try to touch system catalogs, use notifications, set session GUC variables or do any other fancy stuff. In those cases you get a "not implemented" error when you try to prepare the transaction, and the it aborts. I think I figured out the MVCC snapshot issues, but I haven't really tested it so there could be some nasty race conditions I missed. I won't make it to June 1., I'll be on vacation on May 20-27, and I'm quite busy at work at the moment. I'd like to get the patch committed as soon as the 7.6 release cycle begins, with whatever limitations it has at that time. - Heikki
On Mon, 17 May 2004, Alvaro Herrera Munoz wrote: > I have some confidence in that I will be able to deliver it maybe the last > week of May. I can only hope, however, that it will not be rejected because > it's presented too close to feature freeze. There is no such thing as "too close to feature freeze", nor has there ever been in the past ... other then missing it altogether. Unless there are some serious flaws in the implementation, submitting it on May 31st would get it in ...it isn't expecting to be rock solid, bug free, that is what the beta period is to work out ... What is expected, though, is that you won't disappear after its committed, so that you can fix any bugs reported in a timely manner ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Tue, 18 May 2004, Heikki Linnakangas wrote: > I'd like to get the patch committed as soon as the 7.6 release cycle > begins, with whatever limitations it has at that time. The nice thing of this is that then you have a development cycle for others to help ... your patch lays down the "this is the direction, now add to it" ... I'd love to see 7.6 start off with a bunch of very large patches that can be then fleshed out over the course of the development cycle ... instead of a bunch of patches at the end of teh development cycle cause everyone is trying to squeeze things in ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > On Mon, 17 May 2004, Alvaro Herrera Munoz wrote: > > > I have some confidence in that I will be able to deliver it maybe the last > > week of May. I can only hope, however, that it will not be rejected because > > it's presented too close to feature freeze. > > There is no such thing as "too close to feature freeze", nor has there > ever been in the past ... other then missing it altogether. Unless there > are some serious flaws in the implementation, submitting it on May 31st > would get it in ...it isn't expecting to be rock solid, bug free, that is > what the beta period is to work out ... > > What is expected, though, is that you won't disappear after its committed, > so that you can fix any bugs reported in a timely manner ... Not completely true. If a patch needs major rework or the implemention isn't acceptable, it might be rejected and have to wait --- it has happened before, and PITR might not make it because the April 1 patch wasn't an acceptable implementation. -- 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, Pennsylvania19073
On Wed, 19 May 2004, Bruce Momjian wrote: > Marc G. Fournier wrote: > > There is no such thing as "too close to feature freeze", nor has there > > ever been in the past ... other then missing it altogether. Unless there > > are some serious flaws in the implementation, submitting it on May 31st > > would get it in ...it isn't expecting to be rock solid, bug free, that is > > what the beta period is to work out ... > > > > What is expected, though, is that you won't disappear after its committed, > > so that you can fix any bugs reported in a timely manner ... > > Not completely true. If a patch needs major rework or the implemention > isn't acceptable, it might be rejected and have to wait --- it has > happened before, and PITR might not make it because the April 1 patch > wasn't an acceptable implementation. Which is why I stateed "unless there are some serious flaws in ... " :) ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664