Обсуждение: v6.4.3 ?
For discussion:
I've committed two little changes to CURRENT and REL6_4.
1. ExecBRDeleteTriggers() now free's the return tuple from
the trigger procedure if that isn't the tuple given to it
as OLD. This caused PL/pgSQL triggers BEFORE DELETE to
let backend grow until transaction end.
2. The CHECK constraint qualification trees are only
generated once per query in ExecRelCheck(). EState has a
new field es_result_relation_constraints (a List**).
ExecConstraints() and ExecRelCheck() get the actual
EState as parameter.
The fact that the constraints qualifications where read
in with nodeToString() from ccbin for every single tuple
also caused the backend to grow until transaction end.
Especially the second fix is important. We already had
reports from users of v6.4.2 who ran out of memory when doing
a COPY FROM to tables that have CHECK constraints. And it
would also occur on INSERT and UPDATES for those tables if
many rows affected.
Now that we are going to start v6.5 BETA, isn't it good to
put out v6.4.3 before the hot time begins? And if we find
bugs during v6.5 BETA that could also be fixed in REL6_4, do
so and put out a v6.4.4 the same time we release v6.5.1.
I think this would be a good release strategy. From my
experience with one of the biggest commercial software
products, SAP R/3, I know that it is a safe way for
productional (mission critical) installations to follow
releases this way:
1. Wait for the first bugfix release of a new version.
2. Use the time between the first and the second bugfix
release to adapt new features into the local
applications.
3. Test the second bugfix release with the result of step 2
and upgrade production. If the first bugfix release can
stand for a time long enough without further bugs
reported, use that for this step.
4. Follow subsequent bugfix releases if the fixes in them do
or could be expected to happen in the production.
Doing it this way means, that a mission critical installation
will use v6.4.* until some time after we've put out at least
v6.5.1. Thus, we should care about them.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
jwieck@debis.com (Jan Wieck) writes:
> Now that we are going to start v6.5 BETA, isn't it good to
> put out v6.4.3 before the hot time begins?
I'm beginning to agree with Jan about this. I have in fact been
thinking that I wasn't going to be in any big hurry to install 6.5
on my company's mission-critical server, because of the size of the
changes being put in place (MVCC etc). We ran 6.4 in early alpha
stage because we had to --- we were getting bitten by 6.3.2 bugs ---
but 6.4 has been pretty stable for us and so we're probably going
to take a wait-and-see attitude about 6.5.
I don't want to see the Postgres group put a *lot* of time into
maintaining back-rev versions, but when we can easily retrofit an
important bugfix into the prior release we should probably do it.
I do say that back-rev maintenance should be bugfixes only, no
feature upgrades. Adding features would not only be more work,
but it would go against the whole point of the exercise, which is
to provide as stable a release as we possibly can.
The good news is that Postgres is getting used for real,
mission-critical work. Every project should have such problems ;-)
regards, tom lane
> 3. Test the second bugfix release with the result of step 2 > and upgrade production. If the first bugfix release can > stand for a time long enough without further bugs > reported, use that for this step. > > 4. Follow subsequent bugfix releases if the fixes in them do > or could be expected to happen in the production. > > Doing it this way means, that a mission critical installation > will use v6.4.* until some time after we've put out at least > v6.5.1. Thus, we should care about them. Now I see why you patching against 6.4. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Sun, 7 Feb 1999, Bruce Momjian wrote:
> > 3. Test the second bugfix release with the result of step 2
> > and upgrade production. If the first bugfix release can
> > stand for a time long enough without further bugs
> > reported, use that for this step.
> >
> > 4. Follow subsequent bugfix releases if the fixes in them do
> > or could be expected to happen in the production.
> >
> > Doing it this way means, that a mission critical installation
> > will use v6.4.* until some time after we've put out at least
> > v6.5.1. Thus, we should care about them.
>
> Now I see why you patching against 6.4.
The arguments for a v6.4.3 make sense to me...tell me when you wish for
this to be created, and it shall be done :)
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> > Doing it this way means, that a mission critical installation
> > will use v6.4.* until some time after we've put out at least
> > v6.5.1. Thus, we should care about them.
>
> Now I see why you patching against 6.4.
That's the reason. One of the biggest drawbacks against
Postgres is (for many companies at least), that you can't buy
support.
If we only care a little for the last official release
branch, it'll be much better than any payable support for a
commercial product. Yes, I believe it - we have the power.
I recall some replies to recent problem reports on v6.3.2
where we told "upgrade to v6.4.2" (shame on us). That's
easier said than done, if someone has big applications
breaking on new features.
I know that it isn't true, but these "upgrade to another
release" answers instead of "install bugfix release vX.X.X"
look like we don't care about anyone who really uses
Postgres, not only playing around with it just for fun.
That's the sound of M$.
Patching against v6.4 takes time. It must be done manually
nearly all the time since patches don't apply clean. But it's
the only way to give Postgres a real good reputation.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
Marc G. Fournier wrote:
> On Sun, 7 Feb 1999, Bruce Momjian wrote:
>
> > Now I see why you patching against 6.4.
>
> The arguments for a v6.4.3 make sense to me...tell me when you wish for
> this to be created, and it shall be done :)
A week or so before we start v6.5 BETA will be enough so I
have the time to build the v6.4.3 feature patch before having
to respond to v6.5 BETA calls.
Don't remember what's all fixed between v6.4.2 and now.
Does anyone else know about bugs that are still in the REL6_4
branch and could be fixed without adding features?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
jwieck@debis.com (Jan Wieck) writes:
> Don't remember what's all fixed between v6.4.2 and now.
> Does anyone else know about bugs that are still in the REL6_4
> branch and could be fixed without adding features?
I just checked in the ". conftest.sh" -> ". ./conftest.sh" fix to
configure, which several people have complained of (6.4.2 fails
if "." is not in your PATH at configure time).
We have to be pretty careful with these back-rev patches, since they
typically aren't going to get much testing in the back version's
CVS tree. So I'm leery of applying anything that hasn't been tested
for a while in the development branch.
For example, the patch I just applied to CURRENT to link libpgtcl.so
with -lcrypt perhaps ought to go into REL6_4 --- but I'm afraid to do
that until we verify that it works on a variety of platforms. It fixes
things on teo's Linux box but I worry that it might actually break things
elsewhere.
regards, tom lane
On Sun, Feb 07, 1999 at 05:51:08PM -0500, Tom Lane wrote: > jwieck@debis.com (Jan Wieck) writes: > > Don't remember what's all fixed between v6.4.2 and now. > > Does anyone else know about bugs that are still in the REL6_4 > > branch and could be fixed without adding features? > > I just checked in the ". conftest.sh" -> ". ./conftest.sh" fix to > configure, which several people have complained of (6.4.2 fails > if "." is not in your PATH at configure time). > > We have to be pretty careful with these back-rev patches, since they > typically aren't going to get much testing in the back version's > CVS tree. So I'm leery of applying anything that hasn't been tested > for a while in the development branch. > > For example, the patch I just applied to CURRENT to link libpgtcl.so > with -lcrypt perhaps ought to go into REL6_4 --- but I'm afraid to do > that until we verify that it works on a variety of platforms. It fixes > things on teo's Linux box but I worry that it might actually break things > elsewhere. Just a short note: -lcrypt is available on glibc 2 systems only. And yes please release a 6.4.3. As a administrator of some sites which rely on PostgreSQL heavily I would never use a zero-numbered version. The risk is just too high and too unforseeable. An example: Before 6.4, we used a table called "user" without any problems. Unfortunately, this was not possible in 6.4.x, because it became a reserved keyword there. Having one release together with maintenance updates minimizes the risk of getting features you don't want. -- Regards, Sascha Schumann| Consultant | finger sas@schell.de | forPGP public key
Tom Lane wrote:
> We have to be pretty careful with these back-rev patches, since they
> typically aren't going to get much testing in the back version's
> CVS tree. So I'm leery of applying anything that hasn't been tested
> for a while in the development branch.
Over careful! They might rely on new features that aren't
there. So it's better to wait for a v6.4.* based bug report
and fix them by hand instead of appying complete patches that
fix it on the fly.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
I will update the stuff in the REL6_4 tree for 6.4.3.
> On Sun, 7 Feb 1999, Bruce Momjian wrote:
>
> > > 3. Test the second bugfix release with the result of step 2
> > > and upgrade production. If the first bugfix release can
> > > stand for a time long enough without further bugs
> > > reported, use that for this step.
> > >
> > > 4. Follow subsequent bugfix releases if the fixes in them do
> > > or could be expected to happen in the production.
> > >
> > > Doing it this way means, that a mission critical installation
> > > will use v6.4.* until some time after we've put out at least
> > > v6.5.1. Thus, we should care about them.
> >
> > Now I see why you patching against 6.4.
>
> The arguments for a v6.4.3 make sense to me...tell me when you wish for
> this to be created, and it shall be done :)
>
> Marc G. Fournier
> Systems Administrator @ hub.org
> primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
>
>
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
> That's the reason. One of the biggest drawbacks against > Postgres is (for many companies at least), that you can't buy > support. > > If we only care a little for the last official release > branch, it'll be much better than any payable support for a > commercial product. Yes, I believe it - we have the power. > > I recall some replies to recent problem reports on v6.3.2 > where we told "upgrade to v6.4.2" (shame on us). That's > easier said than done, if someone has big applications > breaking on new features. I agree. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Marc G. Fournier wrote: > > > On Sun, 7 Feb 1999, Bruce Momjian wrote: > > > > > Now I see why you patching against 6.4. > > > > The arguments for a v6.4.3 make sense to me...tell me when you wish for > > this to be created, and it shall be done :) > > A week or so before we start v6.5 BETA will be enough so I > have the time to build the v6.4.3 feature patch before having > to respond to v6.5 BETA calls. > > Don't remember what's all fixed between v6.4.2 and now. > > Does anyone else know about bugs that are still in the REL6_4 > branch and could be fixed without adding features? OK. I will make a 6.5 changes list, and you can see what we have. Do you want to make it as a patch, or a full release with a release number? -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Sascha Schumann <sas@schell.de> writes:
> On Sun, Feb 07, 1999 at 05:51:08PM -0500, Tom Lane wrote:
>> For example, the patch I just applied to CURRENT to link libpgtcl.so
>> with -lcrypt perhaps ought to go into REL6_4 --- but I'm afraid to do
>> that until we verify that it works on a variety of platforms.
> Just a short note:
> -lcrypt is available on glibc 2 systems only.
-lcrypt exists on a variety of systems --- you're showing undue
Linux-centrism here. But what I did was to set up the makefiles
so that -lcrypt is included in the shared library link commands
only if configure found that libcrypt exists. We've done this
for libpq itself since 6.4, and have not heard complaints, so
I'm probably being overly conservative to worry that it might
break the higher-level libraries.
regards, tom lane
Hi all > > That's the reason. One of the biggest drawbacks against > > Postgres is (for many companies at least), that you can't buy > > support. IMHO ... Well, yes one can, one may just need to look around a bit... and pay commercial support prices. Example: As for my self I feel confident that I could provide such support, having been using Postgres+ since Postgres 0.95? (3?4 years ago?). I charge $25/hour, but have been considering going to $30/hour. While I've yet to get a PostgreSQL specific job, I have had some other Linux based jobs. I'll bet that there are many people scattered around the globe that can also provide such support. Perhaps it might be of benefit to both the PostgreSQL image and companies considering using PostgreSQL if there where a support team around the world that could be called on. So, that said, what does every one think of the idea of maintaining on the PostgreSQL web site a contact list of "Authorized Support Centers"? Presto, instant commercial support around the globe. In addition, some time back there was a lot of talk about how to raise some money to support PostgreSQL development. Well, what if 2%? 5%? or so of money earned (related to PostgreSQL) from such official support centers went back to the PostgreSQL development group (what ever that is.). PostgreSQL is one of the top 2 or 3 choices to run on Linux, maybe the 1st choice. And Linux is now exploding in popularity, both in the home and in the company (I just came from a job where half the computers where Linux boxes -- ~40 employees, all with computers.) So, this means that the need for such support will become acute in the next year or two, and if PostgreSQL already has such a system in place and debugged, then that alone could put PostgreSQL way out ahead of all the other choices. Just my thoughts on the matter. Thanks for reading this far, Have a great day Terry Mackintosh <terry@terrym.com> http://www.terrym.com sysadmin/owner I'm excited about life! How about YOU!? Proudly powered by R H Linux 4.2, Apache 1.3.x, PHP 3.x, PostgreSQL 6.x ----------------------------------------------------------------------- Only if you know where you're going can you get there.
Terry Mackintosh wrote:
>
> Hi all
>
> > > That's the reason. One of the biggest drawbacks against
> > > Postgres is (for many companies at least), that you can't buy
> > > support.
>
> IMHO ...
>
> Well, yes one can, one may just need to look around a bit... and pay
> commercial support prices.
>
> Example:
> As for my self I feel confident that I could provide such support, having
> been using Postgres+ since Postgres 0.95? (3?4 years ago?). I charge
> $25/hour, but have been considering going to $30/hour. While I've yet to
> get a PostgreSQL specific job, I have had some other Linux based jobs.
>
> [...]
Nice idea.
But a word of caution seems appropriate.
Commercial support doesn't mean only that you can hire
someone who takes care about your actual problems with the
product. It also means that there is someone you can bill if
that product caused big damage to you (product warranty).
Commercial support doesn't mean only that you hire someone on
a T/M base (time and material). It also means that you can
sign a support contract with a regular payment and have
written down response- and maximum problem-to-fix times,
escalation levels etc.
For these issues (and there are more) you would need an
assurance in the background (or a big company). But this
requires that you have quality assurance management on top of
the development. And that you have aggreed procedures where
escalation levels from your support activate the core
developers in specified times to solve problems. And it
requires that you have more precise product specifications
telling what the product can and where it's limits are.
Otherwise you wouldn't be able to pay the assurance.
There are already distributions of Linux out where you can
buy commercial support with them. They stay behind the
bleeding edge of development and are offered by companies,
that have their own development team apart from the internet
community.
Looking at how we are organized (or better unorganized), all
this high level commercial support seems far away.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
Jan Wieck wrote: > > Terry Mackintosh wrote: > > > > > Hi all > > > > > > That's the reason. One of the biggest drawbacks against > > > > Postgres is (for many companies at least), that you can't buy > > > > support. > > > > IMHO ... > > > > Well, yes one can, one may just need to look around a bit... and pay > > commercial support prices. > > > > Example: > > As for my self I feel confident that I could provide such support, having > > been using Postgres+ since Postgres 0.95? (3?4 years ago?). I charge > > $25/hour, but have been considering going to $30/hour. While I've yet to > > get a PostgreSQL specific job, I have had some other Linux based jobs. > > > > [...] > > Nice idea. > > But a word of caution seems appropriate. > > Commercial support doesn't mean only that you can hire > someone who takes care about your actual problems with the > product. It also means that there is someone you can bill if > that product caused big damage to you (product warranty). > > Commercial support doesn't mean only that you hire someone on > a T/M base (time and material). It also means that you can > sign a support contract with a regular payment and have > written down response- and maximum problem-to-fix times, > escalation levels etc. > Usage decisions also depend on one other MAJOR factor, which Linux has conquered, but I personally feel that PostGres is still a bit shy on: reliability. We use PostGres commercially, and quite frankly have a tough time with it, because of consistent failures with it. Although the price is right, and we hope to stick with PostGres as it matures into a more robust product, others would not touch it when you consider the following reliability problems (admittedly all reported on 6.3): 1. Tables "disappearing" while still listed in the db directory (but no longer visible from the client) 2. Tablesbeing corrupted (i.e. not selectable, not vacuumable, not exportable) 3. Vacuum commands that take longer to runafter one day of table updates than if the table was to be dumped and reloaded (e.g. table with 1.7 million rows,200,000 rows being updated each day) 4. An inability to run multiple clients simultaneously without havingthe backends choke and kick everybody out (we've had to implement a lock manager that restricts db access to one client at a time) (Part of the test suite should be an 8 hour or so load test that has multiple clients reading/writing to the same/different tables...might be surprised what you find) 5. Memory leaks/poor mem managementin various components that need to be worked around (vacuum, insert of existing rec into uniquely indexedtable) Linux is successful because it is reliable, and because many folks are WILLING to risk an OS that has the perception of being unsupported, if once they install it it will run cleanly. However, anyone using a database for any sort of serious application will generally have a more stringent set of criteria that they apply to their selection process. I.e. PostGres is tackling a tougher market than Linux is tackling, and it will have to be correspondingly more mature in order to enjoy the same success. Reword? We would be happier if someone were to iron all the problems out of postgres that make it unreliable, and not very robust, than if someone were to provide commercial support (which will NOT fix the aforementioned problems!) Thomas ------------------------------------------------------------ Thomas Reinke Tel: (416) 460-7021 Director of Technology Fax: (416) 598-2319 E-Soft Inc. http://www.e-softinc.com
On Sun, Feb 07, 1999 at 10:06:03PM +0100, Jan Wieck wrote: > I recall some replies to recent problem reports on v6.3.2 > where we told "upgrade to v6.4.2" (shame on us). That's > easier said than done, if someone has big applications > breaking on new features. Agreed. > I know that it isn't true, but these "upgrade to another > release" answers instead of "install bugfix release vX.X.X" > look like we don't care about anyone who really uses > Postgres, not only playing around with it just for fun. > That's the sound of M$. And once more I agree. > Patching against v6.4 takes time. It must be done manually > nearly all the time since patches don't apply clean. But it's > the only way to give Postgres a real good reputation. I like this approach. However, when d we stop maintaining the old version? I think there are still people using 6.3 who cannot simply upgrade to 6.4. So do we create 6.3.3 too? Or are there no open bug reports on 6.3 anymore? Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael.Meskes@gmx.net | Use PostgreSQL!
On Mon, 8 Feb 1999, Michael Meskes wrote:
> On Sun, Feb 07, 1999 at 10:06:03PM +0100, Jan Wieck wrote:
> > I recall some replies to recent problem reports on v6.3.2
> > where we told "upgrade to v6.4.2" (shame on us). That's
> > easier said than done, if someone has big applications
> > breaking on new features.
>
> Agreed.
>
> > I know that it isn't true, but these "upgrade to another
> > release" answers instead of "install bugfix release vX.X.X"
> > look like we don't care about anyone who really uses
> > Postgres, not only playing around with it just for fun.
> > That's the sound of M$.
>
> And once more I agree.
>
> > Patching against v6.4 takes time. It must be done manually
> > nearly all the time since patches don't apply clean. But it's
> > the only way to give Postgres a real good reputation.
>
> I like this approach. However, when d we stop maintaining the old version? I
> think there are still people using 6.3 who cannot simply upgrade to 6.4. So
> do we create 6.3.3 too? Or are there no open bug reports on 6.3 anymore?
One version back, in my opinion...v6.5's release kills anythingolder then
v6.4, v6.6's release kills anything older then v6.5, etc...
And, no, we aren't "supporting" v6.3 at this time, since this is a new
thing...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> I like this approach. However, when d we stop maintaining the old version? I > think there are still people using 6.3 who cannot simply upgrade to 6.4. So > do we create 6.3.3 too? Or are there no open bug reports on 6.3 anymore? We keep releasing versions until no show-stopper bugs exist. 6.4.* had one on COPY bug that Jan is fixing. The others have workarounds, and we are so quick at pointing people to these work-arounds, I don't think they warrant a new release. We get so many improvements with each release, it is tough to back-patch those into the tree. At some point, the 6.3.* tree would match the 6.4.* tree. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> We keep releasing versions until no show-stopper bugs exist.
> 6.4.* had one on COPY bug that Jan is fixing. The others have
> workarounds, and we are so quick at pointing people to these
> work-arounds, I don't think they warrant a new release.
I posted one or two patches into the /pub/patches directory, and am not
sure whether I bothered installing them into the v6.4.x tree since it
may have been declared dead at that point. Be sure and check (or get a
message from me after I've checked) that they have been applied before
releasing v6.4.3...
- Tom
> > We keep releasing versions until no show-stopper bugs exist. > > 6.4.* had one on COPY bug that Jan is fixing. The others have > > workarounds, and we are so quick at pointing people to these > > work-arounds, I don't think they warrant a new release. > > I posted one or two patches into the /pub/patches directory, and am not > sure whether I bothered installing them into the v6.4.x tree since it > may have been declared dead at that point. Be sure and check (or get a > message from me after I've checked) that they have been applied before > releasing v6.4.3... > We can't just do 6.4.2 patches, can we? That would be nice. We getting near starting beta, and will not have lots of time to test things. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> We can't just do 6.4.2 patches, can we? That would be nice. We
> getting near starting beta, and will not have lots of time to test
> things.
Personally, I would choose to post patches, since as you point out we
are really focused on v6.5beta. We *still* need a patch convention with
a .../patches/ directory shipped with Postgres, and with routines to
help create and apply the patches.
I would suggest that for the future we create a top level directory
called "patches", and within that directory have two routines, perhaps
CreatePatch, CreatePackage, and ApplyPatch. CreatePatch would create a
subdirectory, look for all .orig files and make separate patch files for
each inside the subdirectory. Type a README and post a tar file of the
subdirectory at ftp://postgresql.org/pub/patches/. On the other end,
ApplyPatch could print the README, prompt for an "OK to continue?", and
apply the specified patches.
If there is already a common package for doing this we could use that of
course.
I might have time to do this for v6.5 unless someone else wants to give
it a shot. I have some code which could form the basis for this (and I
know that Bruce has something in the source tree which he uses but which
imho does not have enough of the features mentioned above; my current
code is lacking some of these also)...
- Tom
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:
> Personally, I would choose to post patches, since as you point out we
> are really focused on v6.5beta. We *still* need a patch convention with
> a .../patches/ directory shipped with Postgres, and with routines to
> help create and apply the patches.
The trouble with maintaining a pile of independent patches is that you
have cross-patch dependencies: patch B fails to apply unless patch A
was previously installed, or applies but fails to work right, etc etc.
Worse, an installation reporting a problem might be running a slightly
different set of patches than anyone else, complicating the diagnosis
substantially.
So, while tossing a patch into a "patches" directory sounds easy,
I fear it will lead to more effort overall, both for developers and
users. It also doesn't advance the goal of creating super-stable
versions for people who have chosen to run a back revision for
reliability reasons.
I think the approach already discussed is better: apply bug fixes
(but not feature additions) to the previous release's CVS branch
whenever practical, and put out a dot-N version every so often.
> I would suggest that for the future we create a top level directory
> called "patches", and within that directory have two routines, perhaps
> CreatePatch, CreatePackage, and ApplyPatch.
This would be worth doing in order to simplify life for people working
on the code --- it'd be easier to package up and mail in a set of
changes, and easier to apply them. But I don't think it's an answer
for back-rev maintenance.
regards, tom lane
> "Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes: > > Personally, I would choose to post patches, since as you point out we > > are really focused on v6.5beta. We *still* need a patch convention with > > a .../patches/ directory shipped with Postgres, and with routines to > > help create and apply the patches. > > The trouble with maintaining a pile of independent patches is that you > have cross-patch dependencies: patch B fails to apply unless patch A > was previously installed, or applies but fails to work right, etc etc. > Worse, an installation reporting a problem might be running a slightly > different set of patches than anyone else, complicating the diagnosis > substantially. My optimizer fix will not affect other patches. If we only have a few patches, they will not bump into each other. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Tue, 9 Feb 1999, Tom Lane wrote:
> "Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:
> > Personally, I would choose to post patches, since as you point out we
> > are really focused on v6.5beta. We *still* need a patch convention with
> > a .../patches/ directory shipped with Postgres, and with routines to
> > help create and apply the patches.
>
> The trouble with maintaining a pile of independent patches is that you
> have cross-patch dependencies: patch B fails to apply unless patch A
> was previously installed, or applies but fails to work right, etc etc.
> Worse, an installation reporting a problem might be running a slightly
> different set of patches than anyone else, complicating the diagnosis
> substantially.
>
> So, while tossing a patch into a "patches" directory sounds easy,
> I fear it will lead to more effort overall, both for developers and
> users. It also doesn't advance the goal of creating super-stable
> versions for people who have chosen to run a back revision for
> reliability reasons.
>
> I think the approach already discussed is better: apply bug fixes
> (but not feature additions) to the previous release's CVS branch
> whenever practical, and put out a dot-N version every so often.
I kinda agree with this one also...as Tom's says, at least ppl can't say
"Patch B broke things", but they didn't apply Patch A, which B's fixes
used features from...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> I kinda agree with this one also...as Tom's says, at least ppl can't
> say "Patch B broke things", but they didn't apply Patch A, which B's
> fixes used features from...
*shrug* I don't have a strong feeling about it, and would be happy to
carry along two versions. Especially if one or a few people wanted to
adopt the earlier version to ensure that patches get tested before being
applied and to ensure that builds get tested before release. Over long
periods of time we will accumulate more than a few patches, and there
needs to be some way to ensure the integrity and ongoing testing of the
older tree between releases.
So, are we releasing v6.4.3? If so, when? I'll need to scrub it for
outstanding patches...
- Tom