> Once we have the changes, the next question is do we want to risk
> back-patching them into 6.5.2? I can see several ways that we could
> proceed:
> 1. Back-patch into REL6_5, and postpone 6.5.2 release for a while
> for beta-testing.
> 2. Put out 6.5.2 now (since it already has several other useful fixes),
> then back-patch, and release 6.5.3 after a beta-testing interval.
> 3. Leave these changes out of 6.5.*, and try to get 6.6 out the door
> soon instead.
>
> I am not eager to hurry 6.6 along --- I have a lot of half-done work
> in the planner/optimizer that I'd like to finish for 6.6. Perhaps
> choice #2 is the way to go. Comments?
>
> regards, tom lane
I woudl also suggest number 2 would be best for all. It means teh bugfix for
my (and potentially other peoples) problems gets fixed before 6.6 but there
is no delay to the 6.5.2 bugfixes being released.
I am curious, is there a reason that there is not a regular release of the
development tree also? I am aware we can get it through CVS to hammer
on it, but releases would be easier in many ways, certainly easier to develop
patches against.
Just a thought, as it seems that the linux kernel benefits greatly from
this approach.
As a final word, I would like to thank tom for his looking into
the problem. I have been really impressed with the responses
of the postgresql developers, they seem to be a lot more approachable and
willing to fix problems than in most other open source systems I have
seen.
Hopefully when I get a bit more time and get more familiar with the
postgresql code, I'll be able to actually provide some solutions
instead of just breaking it and telling you lot {:-)
Thanks!
~Michael