[#CORE-1575] serious memory bug on multiple update a table in a single transaction

Firebird Core

serious memory bug on multiple update a table in a single transaction

Created: 08/Nov/07 07:46 AM Updated: 23/Feb/11 01:17 PM

Component/s:

Engine

Affects Version/s:

2.0.2, 2.0.3, 2.1 Beta 2

Fix Version/s:

2.5 Beta 1

Time Tracking:

Not Specified

File Attachments:

MemoryBug.zip (2.60 MB)

Environment:

Windows Vista Business, 2 GB RAM, Firebird 2.0.3 Super Server

Issue Links:

Relate

This issue relate to:

~~CORE-1477~~ Avoiding excessive memory consumption by undo-log after series of updates

This issue is related to:

CORE-381 Slow updates after first UPDATE

Target:

2.5.0

Description

« Hide

Dear all,

I found a serious bug leading Firebird in allocating a very large amount of RAM - in my example (with 80.000 records) it crashes after allocating 1.7 GB of RAM.

You can reproduce this bug by using the attached database "MemoryBug.fdb" by execute the following two queries WITHOUT commiting after the first query.

Query A:
======

update mytable
set CIS = 0;

==> Firebird uses (with my DefaultDBCachePages) approx. 90 MB of RAM.

Query B:
======

update mytable
set CIS = 1;

==> use of RAM for the Firebird servers grows in a few seconds up to 1.7 GB + and crashes.

Note 1: It seems that updating records several times in the SAME transaction leads in this bug. If one commits after the first query, every works fine.

Note 2: Using a stored procedure including the two above statements DOESN'T lead in growing memory that much (just up to about 180 MB in my case).

Note 3: Using tables with less fields as in my example seems to work correctly. Therefore: Use my example database to reproduce the bug!

Note 4: I guess the bug reported by Eugene Kuznetsov in ~~CORE-1477~~ is the same.

It is essential for the further development of my project to have a solution for this. So please, let me know, when this bug will be fixed.

Thanks in advance.

Daniel Bauten

All

Comments

Work Log

Change History

Version Control

Subversion Commits

Sort Order:

[ Permalink | « Hide ]

Daniel Bauten added a comment - 08/Nov/07 07:50 AM - edited

A small database with one table ('MYTABLE') containing about 80.000 records.

Just use the following two queries WITHOUT commiting after the first one to "see" the bug reported in ~~CORE-1575~~.

update mytable
set CIS = 0;

update mytable
set CIS = 1;

[ Permalink | « Hide ]

Daniel Bauten added a comment - 26/Nov/07 02:49 AM

Dear Dmitry,

three years ago for „CORE-381" you wrote that this is a design pitfall...

As I mentioned this bug leads in several problems for my actual project. Can you tell me when this will be fixed?

Thanks in advance for your help, Dmitry.

Daniel

[ Permalink | « Hide ]

Dmitry Yemanov added a comment - 26/Nov/07 03:17 AM

Second update in the same transaction transforms the delta record to a full record version, hence requiring more I/O. This is by design and unlikely to change. The big memory consumption is another (although related) issue which hopefully can be optimized. I have a draft solution ready, but it requires some more work.

[ Permalink | « Hide ]

Daniel Bauten added a comment - 26/Nov/07 03:51 AM

I see. Then I will check the memory consumption for "my database" after ~~CORE-1477~~ is fixed. As you have a draft solution, is it possible to fix the big memory consumption (i.e. ~~CORE-1477~~) in Firebird 2.1 Final?