Re: [HACKERS] Open 6.4 items
От | Marc G. Fournier |
---|---|
Тема | Re: [HACKERS] Open 6.4 items |
Дата | |
Msg-id | Pine.BSF.4.02.9810051428510.29733-100000@hub.org обсуждение исходный текст |
Ответ на | Re: [HACKERS] Open 6.4 items (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Open 6.4 items
|
Список | pgsql-hackers |
On Mon, 5 Oct 1998, Tom Lane wrote: > "Marc G. Fournier" <scrappy@hub.org> writes: > > Rename as 'release stopper'... > >> notify fixes(Tom) > >> [other items snipped] > > These have obviously become show stoppers, since they are now half > > implemented, and have to be completed before release. Do we have ETAs on > > this stuff? > > My notify rewrite is not in the tree at all right now. I thought we had > agreed (off-list) not to put that change into 6.4, but to postpone it > to the next release. *slap forehead* > > As things stand right now, we are looking at November 1st > > for a release date on v6.4...a month late, but not much worse then other > > releases :) > > On the other hand, if release is going to be 11/1 not 10/1, my personal > vote is to put the notify changes in. If there are any bugs, that ought > to be time enough to shake them out. > > I can commit those changes tonight if I have the go-ahead. Or I can > wait till post-6.4. Your call. Go for it...that will at least get them off the list... > flock is a release stopper as far as I'm concerned, because the backend > *does not compile* on my platform without diking out that code. I agree > that it is too late to try to rewrite the feature correctly for 6.4. > What say we put in an autoconf test for whether flock exists, and make > the new code conditional on that? People without flock would see the > same old behavior, which is good enough for now. I will volunteer to > make the necessary changes if that strategy is agreed on. Make it so...
В списке pgsql-hackers по дате отправления: