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

Database with many grants gets corrupted after backup + restore [CORE2285] #2711

Closed
firebird-automations opened this issue Jan 21, 2009 · 15 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: michalk1 (michalk1)

Is related to CORE1770

Attachments:
GrantTest.zip
2285.tgz
GrantTest2.zip

May be related to CORE1957 or CORE2223, but persists in 2.1.2 RC1.

1) Create database with 300 tables and grant them to 100 users (30 000 grants in total)

2) Backup + restore the database

3) Revoke all grants from one user in single transaction (300 revocations in total). After commit there is an error:

internal gds software consistency check (cannot find record back version (291), file: vio.cpp line: 5029)

Commits: 4df924e 8a5e606

@firebird-automations
Copy link
Collaborator Author

Commented by: michalk1 (michalk1)

I attach a simple testcase. Database backup + restore is done through services api in this case, but it doesn't make a difference.

@firebird-automations
Copy link
Collaborator Author

Modified by: michalk1 (michalk1)

Attachment: GrantTest.zip [ 11310 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

assignee: Alexander Peshkov [ alexpeshkoff ]

@firebird-automations
Copy link
Collaborator Author

Modified by: michalk1 (michalk1)

description: May be related to CORE1957 or CORE2223, but persists in 2.1.2 RC1.

1) Create database with 100 tables and grant them to 300 users (30 000 grants in total)

2) Backup + restore the database

3) Revoke all grants from one user in single transaction (100 revocations in total). After commit there is an error:

internal gds software consistency check (cannot find record back version (291), file: vio.cpp line: 5029)

=>

May be related to CORE1957 or CORE2223, but persists in 2.1.2 RC1.

1) Create database with 300 tables and grant them to 100 users (30 000 grants in total)

2) Backup + restore the database

3) Revoke all grants from one user in single transaction (300 revocations in total). After commit there is an error:

internal gds software consistency check (cannot find record back version (291), file: vio.cpp line: 5029)

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

Sorry, I could not reproduce this bug.
I've used ISQL to perform all actions, cause Delphi is not acceptable to me. May be this is clearly windows case?

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

Attachment: 2285.tgz [ 11320 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: michalk1 (michalk1)

In my original comment I exchanged count of tables and users (I updated it later). I create 300 tables and grant them to 100 users in the testcase, it seems that when the numbers are exchanged, the error is less likely. Try it again please with the replaced numbers, you may use a new script I attach. I can reproduce the error both at Windows and Linux servers (32-bit, default configuration) on condition the server variant is Superserver (can't reproduce it with Clasic). Remember to backup and restore the database before you revoke the grants.

@firebird-automations
Copy link
Collaborator Author

Modified by: michalk1 (michalk1)

Attachment: GrantTest2.zip [ 11330 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

Issue confirmed.
Sooner of all fix will be available only in 2.5, cause error is rare enough, but changes needed to fix it reliably are rather massive. You can make error much less possible on 2.1 setting
GCPolicy = cooperative
in firebird.conf.

PS. It's not related with CORE1957 or CORE2223.

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

Link: This issue is related to CORE1770 [ CORE1770 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

dfw.epp is keeping is task_table[] pointer to it's internal static routines. The only exception from this rule is GRANT_privileges, which therefore was left not fixed in 1770.

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

Now all DB modifications in grant.epp happen in user (not system) transaction.

@firebird-automations
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

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

resolution: Fixed [ 1 ]

Fix Version: 2.5 Beta 1 [ 10251 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

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

@firebird-automations
Copy link
Collaborator Author

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
Development

No branches or pull requests

2 participants