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

Bugcheck on queries containing WITH LOCK clause [CORE5576] #5843

Closed
firebird-automations opened this issue Jul 3, 2017 · 6 comments
Closed

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @romansimakov

Attachments:
c5576.bat.7z

Reproducible example:

Create a database (say /tmp/wl.fdb) by script
create database '/tmp/wl.fdb';

create table t (
i integer not null primary key,
d char(1024) computed by ('qwert'),
s varchar(8192)
);

insert into t values (1, 'format1opqwertyuiopqwertyuiop');
commit;

Then perform backup/restore operation:
./gbak -b /tmp/wl.fdb stdout | ./gbak -c -rep stdin /tmp/wlr.fdb

Now if you run
select * from t where i=1 with lock;
it results in writing broken record version and the next run
select * from t where i=1;
will lead to bugcheck.

Explanation:
VIO_writelock always sure that it writes delta but in case of example after restore calculated fields there are two formats. VIO_writelock writes a full version of format 1 but not a delta but the functions always set delta flag. To fix it's enough to copy correct behaviour from VIO_modify.

Thanks Vlad for the help in resolving

Commits: 00e5a9f 74b04f8

@firebird-automations
Copy link
Collaborator Author

Modified by: @romansimakov

description: Reproducible example:

Create a database (say /tmp/wl.fdb) by script
create database '/tmp/wl.fdb';

create table t (
i integer not null primary key,
d char(1024) computed by ('qwert'),
s varchar(8192)
);

insert into t values (1, 'format1opqwertyuiopqwertyuiop');
commit;

Then perform backup/restore operation:
./gbak -b /tmp/wl.fdb stdout | ./gbak -c -rep stdin /tmp/wlr.fdb

Now if you run
select * from t where i=1 with lock;
it results in writing broken record version and the next run
select * from t where i=1;
will lead to bugcheck.

Explanation:
VIO_writelock always sure that it writes delta but in case of example after restore calculated fields there are two formats. VIO_writelock writes a full version of format 1 but not a delta but the functions always set delta flag. To fix it's enough to copy correct behaviour from VIO_modify.

=>

Reproducible example:

Create a database (say /tmp/wl.fdb) by script
create database '/tmp/wl.fdb';

create table t (
i integer not null primary key,
d char(1024) computed by ('qwert'),
s varchar(8192)
);

insert into t values (1, 'format1opqwertyuiopqwertyuiop');
commit;

Then perform backup/restore operation:
./gbak -b /tmp/wl.fdb stdout | ./gbak -c -rep stdin /tmp/wlr.fdb

Now if you run
select * from t where i=1 with lock;
it results in writing broken record version and the next run
select * from t where i=1;
will lead to bugcheck.

Explanation:
VIO_writelock always sure that it writes delta but in case of example after restore calculated fields there are two formats. VIO_writelock writes a full version of format 1 but not a delta but the functions always set delta flag. To fix it's enough to copy correct behaviour from VIO_modify.

Thanks Vlad for the help in resolving

@firebird-automations
Copy link
Collaborator Author

Modified by: @romansimakov

assignee: Roman Simakov [ roman-simakov ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @romansimakov

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

resolution: Fixed [ 1 ]

Fix Version: 4.0 Alpha 1 [ 10731 ]

Fix Version: 3.0.3 [ 10810 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

Attachment: c5576.bat.7z [ 13152 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

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

QA Status: No test => Done successfully

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment