Thread: v6.4.3 ?

v6.4.3 ?

From
jwieck@debis.com (Jan Wieck)
Date:
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) #

Re: [HACKERS] v6.4.3 ?

From
Tom Lane
Date:
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


Re: [HACKERS] v6.4.3 ?

From
Bruce Momjian
Date:
>     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
 


Re: [HACKERS] v6.4.3 ?

From
The Hermit Hacker
Date:
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 



Re: [HACKERS] v6.4.3 ?

From
jwieck@debis.com (Jan Wieck)
Date:
> >     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) #

Re: [HACKERS] v6.4.3 ?

From
jwieck@debis.com (Jan Wieck)
Date:
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) #

Re: [HACKERS] v6.4.3 ?

From
Tom Lane
Date:
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


Re: [HACKERS] v6.4.3 ?

From
Sascha Schumann
Date:
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
 


Re: [HACKERS] v6.4.3 ?

From
jwieck@debis.com (Jan Wieck)
Date:
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) #

Re: [HACKERS] v6.4.3 ?

From
Bruce Momjian
Date:
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
 


Re: [HACKERS] v6.4.3 ?

From
Bruce Momjian
Date:
>     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
 


Re: [HACKERS] v6.4.3 ?

From
Bruce Momjian
Date:
> 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
 


Re: [HACKERS] v6.4.3 ?

From
Tom Lane
Date:
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


Commercial support, was Re: [HACKERS] v6.4.3 ?

From
Terry Mackintosh
Date:
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.



Re: Commercial support, was Re: [HACKERS] v6.4.3 ?

From
jwieck@debis.com (Jan Wieck)
Date:
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) #

Re: Commercial support, was Re: [HACKERS] v6.4.3 ?

From
Thomas Reinke
Date:

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


Re: [HACKERS] v6.4.3 ?

From
Michael Meskes
Date:
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!


Re: [HACKERS] v6.4.3 ?

From
The Hermit Hacker
Date:
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 



Re: [HACKERS] v6.4.3 ?

From
Bruce Momjian
Date:
> 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
 


Re: [HACKERS] v6.4.3 ?

From
"Thomas G. Lockhart"
Date:
> 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


Re: [HACKERS] v6.4.3 ?

From
Bruce Momjian
Date:
> > 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
 


Re: [HACKERS] v6.4.3 ?

From
"Thomas G. Lockhart"
Date:
> 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


Re: [HACKERS] v6.4.3 ?

From
Tom Lane
Date:
"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


Re: [HACKERS] v6.4.3 ?

From
Bruce Momjian
Date:
> "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
 


Re: [HACKERS] v6.4.3 ?

From
The Hermit Hacker
Date:
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 



Re: [HACKERS] v6.4.3 ?

From
"Thomas G. Lockhart"
Date:
> 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