Issue Details (XML | Word | Printable)

Key: DOC-89
Type: Task Task
Status: Open Open
Priority: Major Major
Assignee: Paul Vinkenoog
Reporter: Arioch
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.

Temporary BLOBS tends to unexpectedly inflate database file

Created: 29/Jul/13 01:30 PM   Updated: 29/Jul/13 01:31 PM
Component/s: None
Affects Version/s: None
Fix Version/s: None

Environment: Firebird 2.1+,

 Description  « Hide
Recent discussion shown that for many users the fact that long-living transaction may in some conditions uncontrollably inflate database with gigabytes of temporary blobs is unexpected if not confusing.
It does not help, that long-living read-only transaction are told in many FAQs as a valid if not recommended way to work with data (and having parallel short transactions for changing them)

In particular, even read-only requests in read-only transactions (like fetching from calculated columns or views) tend to uncontrollably write a lot of data into database file, which is counterintuitive and i think can be considered as a "gotcha" or trap for novices.

I believe that - until the implementation changes so that temp blobs would be reclaimed before transaction end, and for those versions where this would not be backported to - documentation should proactively warn users about the possibility of this counter-intuitive and damaging scenarios.

This would include:

1) documentation of read-only and/or long-alive transactions: should note that some r/o-looking operations are actually attempts to write data into the database file.
1.1) ditto for read-only database mode
2) documentation of blob concatenations and LIST function (and any other operation, potent of temp blob creation. Typecasts ? UDFs ? whatever? ): should have a notice that this requires write operations on database file and can expand that file with no limits until full-COMMIT or full-ROLLBACK executed
3) documentation of Autonomous Transactions should notice that they do not free associated resources themselves, and as such can uncontrollably increase temporary blobs amount for their parent transaction
4) documentations about monitoring and tools extracting database statistics: should include a pattern, that implies the user really stepped over those rooks.

Probably this should be formed as a separate errata-like document that would be referenced and linked to form the places outlined above.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
There are no subversion log entries for this issue yet.