Issue Details (XML | Word | Printable)

Key: CORE-2266
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Critical Critical
Assignee: Vlad Khorsun
Reporter: Adriano dos Santos Fernandes
Votes: 0
Watchers: 0
Operations

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

Nbackup database locking not working correctly

Created: 04/Jan/09 03:18 PM   Updated: 26/Jan/09 11:42 AM
Component/s: Engine, NBACKUP
Affects Version/s: 2.1.0, 2.5 Alpha 1, 2.1.1
Fix Version/s: 2.1.2, 2.5 Beta 1

Time Tracking:
Not Specified

Environment: Windows / Linux

Planning Status: Unspecified


 Description  « Hide
When the database file is locked for physical copy, it should not change. But test case below shows that it grows.

isql -term !
create database 't.fdb'!
create table t (n integer)!
create procedure sp_load
as
  declare n integer = 0;
begin
  while (n < 50000)
  do
  begin
    insert into t values (:n);
    n = n + 1;
  end
end!

nbackup -L t.fdb

The file sizes are:
t.fdb 692224
t.fdb.delta 12288

isql t.fdb
execute procedure sp_load;

Now the sizes are:
t.fdb 3391488
t.fdb.delta 2551808

 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dmitry Yemanov added a comment - 05/Jan/09 03:51 AM
The ticket is actually about a few calls (PIO_init_data and PIO_expand) not going through the CCH layer and thus ignoring the backup state.

Vlad Khorsun added a comment - 05/Jan/09 04:00 AM
But is it a really bug\bad behavior ? Database file will grow anyway during the merge... And why it is critical ?

Dmitry Yemanov added a comment - 05/Jan/09 04:18 AM
Nobody will be copying the database file during the merge, but this is expected in the stalled state.

Actually, I'm not sure this is really critical. Is a bad file-system level copy of the database possible when the original file is being appended at the end only?

But anyway, I think the current design violates the NBACKUP architecture (at least the layering). Nobody but CCH only should be directly calling PIO for write.

Vlad Khorsun added a comment - 05/Jan/09 04:29 AM
> Is a bad file-system level copy of the database possible when the original file is being appended at the end only?
I doubt it as file appended with zero's. But i agree that size of file-system level copy would be somewhat bigger than expected ;)

> But anyway, I think the current design violates the NBACKUP architecture (at least the layering). Nobody but CCH only should be directly calling PIO for write.
Agree, i'll fix it