Re: Remembering bug #6123
От | Kevin Grittner |
---|---|
Тема | Re: Remembering bug #6123 |
Дата | |
Msg-id | 4F11778602000025000447DF@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Remembering bug #6123 ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: Remembering bug #6123
|
Список | pgsql-hackers |
Tom Lane wrote: > Well, the bottom line that's concerning me here is whether throwing > errors is going to push anyone's application into an unfixable > corner. I'm somewhat encouraged that your Circuit Courts software > can adapt to it, since that's certainly one of the larger and more > complex applications out there. Or at least I would be if you had > actually verified that the CC code was okay with the recently- > proposed patch versions. Do you have any thorough tests you can run > against whatever we end up with? In spite of several attempts over the years to come up with automated tests of our applications at a level that would show these issues, we're still dependent on business analysts to run through a standard list of tests for each release, plus tests designed to exercise code modified for the release under test. For the release where we went to PostgreSQL triggers, that included running lists against the statistics tables to see which trigger functions had not yet been exercised in testing, until we had everything covered. To test the new version of this patch, we would need to pick an application release, and use the patch through the development, testing, and staging cycles, We would need to look for all triggers needing adjustment, and make the necessary changes. We would need to figure out which triggers were important to cover, and ensure that testing covered all of them. Given the discussions with my new manager this past week, I'm pretty sure we can work this into a release that would complete testing and hit pilot deployment in something like three months, give or take a little. I can't actually make any promises on that until I talk to her next week. From working through all the BEFORE triggers with UPDATE or DELETE statements this summer, I'm pretty confident that the ones which remain can be handled by reissuing the DELETE (we didn't keep any of the UPDATEs with this pattern) and returning NULL. The most complicated and troublesome trigger code has to do with purging old data. I suspect that if we include testing of all purge processes in that release cycle, we'll shake out just about any issues we have. -Kevin
В списке pgsql-hackers по дате отправления: