Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Right. And even if it is a bug the question might be "what sort of bug 
> is it?" We might well be prepared to take some risks with code stability 
> to plug security or data corruption bugs, a lot more than we would for 
> other sorts of bugs.

As indeed we have done, and lost the bet more than once :-(.  Rev 8.2.2
and siblings being the most recent example.  A quick review of the
release history will show other cases where well-intentioned, seemingly
safe back-patches broke things.

Now security patches are the worst-case scenario for this, because they
typically go out with no significant public review.  But even a regular
bug-fix patch doesn't get all that much testing in the back branches
before it hits the streets as a supposedly-stable update.  By and large,
if we commit something into REL8_3_STABLE today, it's going to appear
in 8.3.4 with nothing more than buildfarm testing.  That is a sobering
prospect, and not one that makes me want to put nontrivial patches in
there except at great need.

                        regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to