> the first problem you have is that you have a critical production system > that you upgraded without going through proper test first. > That's just bad change control. > In any case, if the new DBD::Pg blew up in your face why did you not > immediately revert to the previous working one? Even if you didn't have it > on disk anymore you can just re-download it explicitly. > If it were no longer on CPAN it is on the 'backpan'. > > Just because its Linux, or Postgresql or Perl, doesn't mean you don't have > to follow proper operational procedures. there were a lot of other things upgraded same time, not only dbd::pg (to minimize total downtime): - our own perl code (with major changes, it's 4mb code size project) - postgresql itself - dbd pg ... all the above has been tested on the special "testing" server prior the upgrade and showed itself stable. Unfortunately it's not always possible to simulate exactly the same situation as in production environment, and as the result the problem didn't show itself up untill we did the upgrade. Because a lot of things were upgraded it wasn't quite obvious right away that it was the result of new DBD::Pg feature, so it took us an hour or two to localize it down to DBD::Pg (which has been downgraded immediately) and then we worked the rest of the time to find out the actual cause and make sure everything else is OK. anyways.... with all that said, I wasn't blaming anyone here and wasn't actually looking for an analyze on how should've we do the upgrade. Rather I'm interested in list's opinion on possible workaround. Though thanks for your point anyway. -- Vlad ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
