Yes, I am aware of the transaction gap problem, having dealt with it
since Interbase 4 day. I am narrowing down the cause, but it will take
a little while to find the culprit, as I don't have direct control
over all the apps that access this database.

Thanks for your suggestions regarding trigger as a cause for infinite
loop that kill resources. I will look into that.

Our Firebird 1.52 server has been crashing daily and I couldn't
pinpoint the cause. The problem seemed to have a different outcome
after upgrading to 2.01. We have other Firebird servers (1.52 and
2.01) that have been absolutely reliable, so I am pretty sure we can
figure this out eventually.

Thanks for your suggestions.

- Jung

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> At 10:54 AM 8/08/2007, you wrote:
> >I just upgraded on of our server from from Firebird 1.52 to 2.01 on
> >Windows 2000. I am encountering this error after the server was up for
> >a few hours:
> >
> >Request depth exceeded. (Recursive definition?)
> >
> >When the server was in this state, simple queries will work, but
> >simple store procedures won't, returning the above error. Restarting
> >the Firebird server service will get rid of the problem until it
> >happens again in a few hours.
> >
> >The other problem I am dealing with is the large gap between the
> >oldest active and the next transaction:
> >
> >ODS version 11.0
> >Oldest transaction 4924198
> >Oldest active 4924199
> >Oldest snapshot 4924199
> >Next transaction 5063357
> >
> >This was a problem before I upgraded to 2.01, but could it be what's
> >killing the server in 2.01 and 1.52 some how was able to handle this
> >better.
>
> No, a garbage gap of ~ 140,000 would tend to slow things down in 2.01
> in the same way as it did in 1.52.
>
> You have an operation somewhere that is in an endless loop. If it's
> just allowed to go on unheeded, eventually it will exhaust resources
> and the server will die. In the meantime, that operation is highly
> likely to be contributing generously to the garbage gap and
> inhibiting garbage collection the way you report.
>
> Have a look at triggers that perform operations on other tables, or
> worse, on their own table or a dependent table. That's a common
> source of recursion and it's a design problem that won't go away on
its own.
>
> ./heLen
>
>
>
> >Help appreciated,
> >
> >- Jung
> >
> >
> >
> >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> >Visit http://www.firebirdsql.org and click the Resources item
> >on the main (top) menu. Try Knowledgebase and FAQ links !
> >
> >Also search the knowledgebases at http://www.ibphoenix.com
> >
> >++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> >Yahoo! Groups Links
> >
> >
> >
>