Re: Remembering bug #6123

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Remembering bug #6123
Date: 2012-01-14 18:39:34
Message-ID: 4F11778602000025000447DF@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marco Nenciarini 2012-01-14 19:09:33 Re: [PATCH] Support for foreign keys with arrays
Previous Message Matthew Draper 2012-01-14 16:10:37 Patch: Allow SQL-language functions to reference parameters by parameter name