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(at)debis(dot)com (Jan Wieck) #