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

[firebird-automations]

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]

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]

Modified by: michalk1 (michalk1)

Attachment: GrantTest.zip [ 11310 ]

[firebird-automations]

Modified by: @dyemanov

assignee: Alexander Peshkov [ alexpeshkoff ]

[firebird-automations]

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]

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]

Modified by: @AlexPeshkoff

Attachment: 2285.tgz [ 11320 ]

[firebird-automations]

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]

Modified by: michalk1 (michalk1)

Attachment: GrantTest2.zip [ 11330 ]

[firebird-automations]

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]

Modified by: @AlexPeshkoff

Link: This issue is related to CORE1770 [ CORE1770 ]

[firebird-automations]

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]

Commented by: @AlexPeshkoff

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

[firebird-automations]

Modified by: @AlexPeshkoff

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

resolution: Fixed [ 1 ]

Fix Version: 2.5 Beta 1 [ 10251 ]

[firebird-automations]

Modified by: @pcisar

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

[firebird-automations]

Modified by: @pavel-zotov

QA Status: No test