gbak multi-database file restore uses wrong minimum number of pages for first database file [CORE5976] #6228
Comments
Modified by: @mrotteveeldescription: I have a Jaybird test that creates a multi-file database using a gbak restore (through the services API). This test creates an artificially small first file. Jaybird instructs Firebird to make the first file 10 pages big, and Firebird then overrides that to 200 pages. This doesn't work correctly, because those 200 pages are not sufficient. As a result the second database file is not created. Firebird 4, the restore logs the following: """ If the minimum is actually 213 or greater, instead of "gbak:length given for initial file (10) is less than minimum (200)", shouldn't it do "gbak:length given for initial file (10) is less than minimum (**212**)" and create the first database file as 212 pages instead of the 200 it does now? For reference, Firebird 3 does create both database files and logs: """ => I have a Jaybird test that creates a multi-file database using a gbak restore (through the services API). This test creates an artificially small first file. Jaybird instructs Firebird to make the first file 10 pages big, and Firebird then overrides that to 200 pages. This doesn't work correctly in Firebird 4, because those 200 pages are not sufficient. As a result the second database file is not created. Firebird 4, the restore logs the following: """ If the minimum is actually 213 or greater, instead of "gbak:length given for initial file (10) is less than minimum (200)", shouldn't it do "gbak:length given for initial file (10) is less than minimum (**212**)" and create the first database file as 212 pages instead of the 200 it does now? For reference, Firebird 3 does create both database files and logs: """ |
Modified by: @mrotteveeldescription: I have a Jaybird test that creates a multi-file database using a gbak restore (through the services API). This test creates an artificially small first file. Jaybird instructs Firebird to make the first file 10 pages big, and Firebird then overrides that to 200 pages. This doesn't work correctly in Firebird 4, because those 200 pages are not sufficient. As a result the second database file is not created. Firebird 4, the restore logs the following: """ If the minimum is actually 213 or greater, instead of "gbak:length given for initial file (10) is less than minimum (200)", shouldn't it do "gbak:length given for initial file (10) is less than minimum (**212**)" and create the first database file as 212 pages instead of the 200 it does now? For reference, Firebird 3 does create both database files and logs: """ => I have a Jaybird test that creates a multi-file database using a gbak restore (through the services API). This test creates an artificially small first file. Jaybird instructs Firebird to make the first file 10 pages big, and Firebird then overrides that to 200 pages. This doesn't work correctly in Firebird 4, because those 200 pages are not sufficient. As a result the second database file is not created. Firebird 4, the restore logs the following: """ If the minimum is actually 212 or greater, instead of "gbak:length given for initial file (10) is less than minimum (200)", shouldn't it do "gbak:length given for initial file (10) is less than minimum (**212**)" and create the first database file as 212 pages instead of the 200 it does now? For reference, Firebird 3 does create both database files and logs: """ |
|
Commented by: @mrotteveel Or maybe raise the minimum from 200 to 300. |
|
Commented by: @AlexPeshkoff I'm sure this can be fixed but one question - does use of multi-file database in an era of multi-terabyte disks really make sense? |
|
Commented by: @mrotteveel @alex In that case, Firebird should drop support for multi-file databases entirely. I'm just pointing out that Firebird attempts to avoid this problem by changing a requested value of 10 pages to a larger value of 200, but that fix is insufficient as the actual minimum is even higher (212). BTW: This sounds to me like there are two separate size constants (or something like that) that should be unified to a single constant. |
|
Commented by: Sean Leyne (seanleyne) Alex, IMO, support for multi-file databases (and multi-file backups) should be eliminated. |
|
Commented by: @AlexPeshkoff In general I agree but must say that it's not trivial task. For example - what to do if user tries to restore multifile .gbk created by some old version? Adding new reasons for arriving unrecoverable backups imho not good idea. |
|
Commented by: @mrotteveel May I suggest that the tangential discussion about removing multifile databases / backups is either taken to the mailing list or to its own issue. Lets not 'pollute' this issue with a discussion. |
|
Commented by: @mrotteveel Any updates on this? |
Modified by: @mrotteveelVersion: 4.0 Beta 1 [ 10750 ] |
|
Commented by: @mrotteveel Pull request: #224 |
|
Commented by: @mrotteveel Vlad merged my pull request |
Modified by: @mrotteveelFix Version: 4.0 Beta 2 [ 10888 ] |
Modified by: @dyemanovassignee: Mark Rotteveel [ avalanche1979 ] |
Submitted by: @mrotteveel
I have a Jaybird test that creates a multi-file database using a gbak restore (through the services API). This test creates an artificially small first file. Jaybird instructs Firebird to make the first file 10 pages big, and Firebird then overrides that to 200 pages.
This doesn't work correctly in Firebird 4, because those 200 pages are not sufficient. As a result the second database file is not created.
Firebird 4, the restore logs the following:
"""
[..]
gbak:backup version is 11
gbak:created database C:\Users\Mark\AppData\Local\Temp\junit8203596626416973464\junit4583341152862574241\testrestore1.fdb, page_size 8192 bytes
gbak:started transaction
gbak:length given for initial file (10) is less than minimum (200)
gbak:adding file C:\Users\Mark\AppData\Local\Temp\junit8203596626416973464\junit4583341152862574241\testrestore2.fdb, starting at page 201
gbak:committing secondary files
gbak:cannot commit files
gbak: ERROR:Starting page number for file C:\USERS\MARK\APPDATA\LOCAL\TEMP\JUNIT8203596626416973464\JUNIT4583341152862574241\TESTRESTORE2.FDB must be 213 or greater
gbak:creating indexes
[..]
"""
If the minimum is actually 212 or greater, instead of "gbak:length given for initial file (10) is less than minimum (200)", shouldn't it do "gbak:length given for initial file (10) is less than minimum (**212**)" and create the first database file as 212 pages instead of the 200 it does now?
For reference, Firebird 3 does create both database files and logs:
"""
[..]
gbak:backup version is 10
gbak:created database C:\Users\Mark\AppData\Local\Temp\junit10807610804273459707\junit7128503662445743782\testrestore1.fdb, page_size 8192 bytes
gbak:started transaction
gbak:length given for initial file (10) is less than minimum (200)
gbak:adding file C:\Users\Mark\AppData\Local\Temp\junit10807610804273459707\junit7128503662445743782\testrestore2.fdb, starting at page 201
gbak:committing secondary files
gbak:creating indexes
[..]
"""
Commits: 3eb47e3 38f5d32
The text was updated successfully, but these errors were encountered: