Re: [HACKERS] Open 6.4 items
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Open 6.4 items |
Дата | |
Msg-id | 22778.907598166@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Open 6.4 items ("Marc G. Fournier" <scrappy@hub.org>) |
Ответы |
Re: [HACKERS] Open 6.4 items
|
Список | pgsql-hackers |
"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. > 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. >> Serious Items >> ------------ >> [snippage] >> generate postmaster pid file and remove flock/fcntl lock code > None of these, IMHO, are release stoppers... 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. regards, tom lane
В списке pgsql-hackers по дате отправления: