Pavel,

> On 16 Jan 2003 at 9:57, Ignacio J. Ortega wrote:
>
> > Sorry to repost, nobody has a clue?
> >
> > I've done some sources research and this error it's emited when a
> > problem is found during VIO_verb_cleanup, any one can
> imagine why this
> > error occurs so often?
>
> If the problem is in VIO_verb_cleanup (undo log cleanup to the
> savepoint), then I guess that you probably have too much changes in
> stored procedures/triggers and one PSQL routine fails (on
> exception or
> error). The problem may occur on pure quantity of changes to
> roll back or
> with conclusion with some race condition (aka bug in engine).
> A chance
> for this multiplies exponencialy when you have procedures
> that call other
> procedures, and all do changes that may fail. This may also occur on
> transaction level when rollback is in progress and you have too much
> changes in a batch, but not very likely, I would bet on proc/triggers.
>
> I have only one suggestion: Try to narrow down the amount of
> changes in
> proc/triggers or isolate those changes to top level procedures or in
> client.
>

Ok, i see, given the structure of the GDB, and the previous deadlock, i
think the problem is what you describe first, it seems that a very inner
SP ( the schema is plenty of SP & TRG that calls other SPs at various
levels ) got a deadlock, and VIO_verb_cleanup screams... hence 290..
sad..

Well, looking for a solution, to change the GDB schema is a big problem,
and to reproduce it is very unlikely in a controled enviroment, do you
have any suspiction of what causes the REAL problem inside? ( silly
question of the century, if you were having any suspiction of the REAL
cause, probably with would be solved long time ago , but i must ask :)..


Saludos,
Ignacio J. Ortega