Issue Details (XML | Word | Printable)

Key: CORE-6121
Type: New Feature New Feature
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Karol Bieniaszewski
Votes: 2
Watchers: 6
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Add switch to gbak to specify initial "Oldest Transaction Number" value on Restore

Created: 12/Aug/19 12:16 PM   Updated: 15/Aug/19 05:02 PM
Component/s: GBAK
Affects Version/s: None
Fix Version/s: None

QA Status: No test


 Description  « Hide
Please add switch to gbak to restore database with specified transaction number.
E.g. Interbase have this as "-START(ING_TRANS)" the name can be different.
I suppose it is very simple to implement as already during restore Firebird start this numbering from 1. Now it should take into account if start it from 1 or specified value from the parameter.

gbak -c -v -START 123456789

and database after restore looks like

Database header page information:
        Flags 0
        Checksum 12345
        Write timestamp Aug 9, 2019 15:17:08
        Page size 4096
        ODS version 16.0
        Oldest transaction 123456790 <- THE SPECIFIED NUMBER +1
        Oldest active 123456791
        Oldest snapshot 123456791
        Next transaction 123456850
        Sequence number 0
        Next attachment ID 0
        Implementation ID 16
        Shadow count 0
        Page buffers 2048
        Next header page 0
        Database dialect 3
        Creation date Aug 9, 2019 15:17:07
        Backup timestamp Aug 9, 2019 15:17:08
        Attributes force write

    Variable header data:
        Sweep interval: 20000
        *END*



 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Sean Leyne added a comment - 12/Aug/19 04:48 PM
The implementation of this feature would first require changes to the backup process to record the last committed transaction number associated with each data row. So, the feature request should be framed in the larger context.

Mark Rotteveel added a comment - 12/Aug/19 06:20 PM
@Sean This wouldn't need a change to the backup process. As far as I understand the requirement, instead of starting the new database with transaction nr 1, the restore will start with the provided transaction nr. It will restore the same data whether your provide the starting transaction id or not.

Sean Leyne added a comment - 12/Aug/19 07:44 PM
@Mark, sorry, I got this mixed up with the IB feature of allowing partial restores... have edited the description/summary to better reflect the requested change.

Vlad Khorsun added a comment - 13/Aug/19 07:45 AM
This feature request is to allow user applications to deal with big transaction numbers.
OK.

But i don't understand - why it should be done using gbak\restore ???

Why not add special option to the CREATE DATABASE statement ?
Or, introduce special SQL statement, say SET NEXT TRANSACTION TO <number> ?

Note, to implement it it is not enough to increment Next on header page.
Engine expects to see *all* TIP pages, even actually unused (with last tx number less than OIT).

Karol Bieniaszewski added a comment - 13/Aug/19 01:22 PM
>> But i don't understand - why it should be done using gbak\restore ???

it looks for me a simplest possible place for such feature and require almost no changes in the Firebird itself.

>> Why not add special option to the CREATE DATABASE statement ?

this can work only for new db but normally someone need to test already existed database.

>>Or, introduce special SQL statement, say SET NEXT TRANSACTION TO <number> ?

this will be good but i suppose it will be harder to implement.

Vlad Khorsun added a comment - 13/Aug/19 02:49 PM
Karol,

believe me - possible implementation have nothing common with restore task.
It anyway could be done inside engine\create_database (or as new SQL statement).

Please, forget about "simplest possible place" and " harder to implement"

Karol Bieniaszewski added a comment - 13/Aug/19 03:09 PM
Ok Vlad, this was not my intention to make this bad but fast ;-)
I only know that team have limited time and the functionality has limited use.

Adriano dos Santos Fernandes added a comment - 13/Aug/19 04:36 PM
If the feature is implemented in engine (create database or something else), it will probably be needed to be also exposed in gbak so records are restored with the high ids.

Vlad Khorsun added a comment - 15/Aug/19 05:02 PM
Adriano,

sure, it could be exposed to gbak. But first it must to be implemented at engine - this is my point.