> 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
