Re: Remembering bug #6123 - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Remembering bug #6123
Date
Msg-id 4F11778602000025000447DF@gw.wicourts.gov
Whole thread Raw
In response to Remembering bug #6123  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: Remembering bug #6123
List 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 by date:

Previous
From: Matthew Draper
Date:
Subject: Patch: Allow SQL-language functions to reference parameters by parameter name
Next
From: Marco Nenciarini
Date:
Subject: Re: [PATCH] Support for foreign keys with arrays