"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