> Vlad,
>
> Thanks for your attention. You can download the backup file using the
> following link (file size is 30 MB):
>
> http://download.motivesys.com/StackProblem.zip
>
> Perhaps you have a chance to download it and use it to reproduce the
> long call stack. If you use EDITBIN.EXE to change the stack size of
> fbserver.exe to 1 MB (1048576), you should be able to get right into it
> by simply trying to restore the backup file in Firebird 2.0.1.12855.

I didn't tried it as i believe you ;) May i ask you to check FB 2.1 against
your database ?

> Such a long call stack sounds dangerous to me and I feel that the
> behavior might be worth changing.
>
> > It can depens on "page buffers" setting if i not mistaken
>
> Can you explain how? Or is this already explained somewhere?

Remember "careful writes" ? Firebird maintains page precedence graph
to maintain database file in consistent state in case of failure. It means that
when some page must be written on disk Firebird will write all high precedence
pages (pages on which our page refers) first. Current code make recursive
calls of write_buffer routine to walk precedence graph. In your case graph have
very big depth therefore stack requirements also high. Why it is so high - is another
question and another investigation. Graph depth can't be more than number of
page buffers in cache - it is obvious.

In FB 2.1 i've changed (improved i think ;) algorithm of page cache flush (flush
called, for example, when transaction commits). New algorithm writes pages which
have no high precedence pages (in sorted order to improve performance), then
another pages which have no high precedence pages, etc, until there are no more
pages to write (it is simplified description). Therefore it have no need to call
write_buffer recursively and lower stack size requirement. Note that lesser stack
depth was not a goal of this new algorithm :)

Page write may occur not only at flush time but when page buffer is needed for
just read from disk page. In this case recursive writes still possible.

Regards,
Vlad