Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > >> Bruce Momjian wrote: >> >>> This is not something we would typically backpatch because of the danger >>> of introducing some unexpected change in libpq. We can provide a patch >>> to anyone who needs it, or if the community wants it backpatched I can >>> certainly do that. >>>
If we start deciding we are not backpatching fixes that we know cause crashes, where is the limit? >> It isn't? It does seem like a bug, which we do typically backpatch ... >> > > Well, it's a risk-reward tradeoff. In this case it seems like there's > a nontrivial risk of creating new bugs against fixing a problem that > evidently affects very few people. I concur with Bruce's feeling that > we shouldn't backpatch ... at least not now. Once the patch has been > through beta testing we could reconsider. > > regards, tom lane > I would like to see this backpatched. Even though the PostgreSQL community hasn't seen a lot of complaints, there have been a number of reports where the bug has caused crashes. Ubuntu launchpad has 6 duplicates for this bug. php has a bug report for it. So it's not like people don't know about it. They just didn't know how to fix it. All that said, I agree it's safer to wait until the 8.4 beta cycle has given this code change a good run before proceeding. In the mean time distributions can either backpatch it themselves or wait for PostgreSQL community to apply the patch. For the environment where I have this problem, I think it's still going to be a up hill battle to get RedHat to incorporate the fix into RHEL5. That's whichever route the community takes with backpatching. Russell.
