Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nbackup database locking not working correctly [CORE2266] #2692

Closed
firebird-issue-importer opened this issue Jan 4, 2009 · 8 comments
Closed

Comments

@firebird-issue-importer
Copy link

@firebird-issue-importer firebird-issue-importer commented Jan 4, 2009

Submitted by: @asfernandes

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

Commits: 2238945 20a4afb

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 5, 2009

Modified by: @dyemanov

assignee: Vlad Khorsun [ hvlad ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 5, 2009

Commented by: @dyemanov

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.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 5, 2009

Commented by: @hvlad

But is it a really bug\bad behavior ? Database file will grow anyway during the merge... And why it is critical ?

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 5, 2009

Commented by: @dyemanov

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.

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 5, 2009

Commented by: @hvlad

> 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

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 6, 2009

Modified by: @hvlad

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.1.2 [ 10270 ]

Fix Version: 2.5 Beta 1 [ 10251 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 26, 2009

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

@firebird-issue-importer
Copy link
Author

@firebird-issue-importer firebird-issue-importer commented Jan 19, 2016

Modified by: @pavel-zotov

QA Status: No test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants