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) #