Increasing ParallelWorkers in firebird.conf causes database restoring to fail

[Tomasz Tyrakowski]

Hello

I've been experimenting with some new settings in Firebird 5 and set
ParallelWorkers to 2 in firebird.conf (FB 5.0.1, classic mode, Debian
12.7, x86_64). MaxParallelWorkers was set to 64.
With this setting, a database backup that normally gets restored without
problems, suddenly failed when activating one of the primary keys
(during the index activation phase, after committing metadata).
The exact error was:

gbak:cannot commit index PK_XYZ
gbak: ERROR:invalid database handle (no active connection)
gbak: ERROR:action cancelled by trigger (3) to preserve data integrity
gbak: ERROR: Cannot deactivate index used by a PRIMARY/UNIQUE constraint
gbak:Exiting before completion due to errors

The PK_XYZ (name obfuscated) is a primary key on a simple integer column
(ID). It is referenced by a couple of foreign keys in other tables.
There's also a trigger fetching a new value for ID from a generator on
insert.
After setting ParallelWorkers=1 the same backup file can be restored
without problems.
Tried both embedded mode and via the server connection (localhost:/...),
the result was the same. Didn't pass -PAR to gbak at all (just -C -V).
Maybe I don't fully understand the new parallel features (only read the
doc suggested in the firebird.conf comment), but it seems strange that
the number of worker threads can cause this kind of error (and what
exactly is the meaning of the error? deactivating an index during
activation phase? why?).
Has anyone had similar experiences? Is increasing ParallelWorkers in
classic mode safe at all (I'm not even asking whether it brings any
benefits, but simply if it's allowed)?

cheers
Tomasz

[Vlad Khorsun]

Hello

I've been experimenting with some new settings in Firebird 5 and set
ParallelWorkers to 2 in firebird.conf (FB 5.0.1, classic mode, Debian
12.7, x86_64). MaxParallelWorkers was set to 64.
With this setting, a database backup that normally gets restored without
problems, suddenly failed when activating one of the primary keys
(during the index activation phase, after committing metadata).
The exact error was:

gbak:cannot commit index PK_XYZ
gbak: ERROR:invalid database handle (no active connection)
gbak: ERROR:action cancelled by trigger (3) to preserve data integrity
gbak: ERROR: Cannot deactivate index used by a PRIMARY/UNIQUE constraint
gbak:Exiting before completion due to errors

  Look at the firebird.log also, it should contain message(s):

Failed to create worker attachment

The PK_XYZ (name obfuscated) is a primary key on a simple integer column
(ID). It is referenced by a couple of foreign keys in other tables.
There's also a trigger fetching a new value for ID from a generator on
insert.
After setting ParallelWorkers=1 the same backup file can be restored
without problems.

  It also will be restored OK if you specify -par (with any non-zero value), or use

services (-se switch), or use SuperServer.

 

Tried both embedded mode and via the server connection (localhost:/...),
the result was the same. Didn't pass -PAR to gbak at all (just -C -V).
Maybe I don't fully understand the new parallel features (only read the
doc suggested in the firebird.conf comment), but it seems strange that
the number of worker threads can cause this kind of error (and what
exactly is the meaning of the error? deactivating an index during
activation phase? why?).

  Classic can't create additional worker attachments required to build indices as 

restoring database is in single-user shutdown mode. Thus it returns error and 

gbak seems not handle it properly. Register it at the tracker, please.

 

Has anyone had similar experiences? Is increasing ParallelWorkers in
classic mode safe at all (I'm not even asking whether it brings any
benefits, but simply if it's allowed)?

  Of course it is safe.

Regards,

Vlad

[Tomasz Tyrakowski]

On 24.09.2024 at 17:37, Vlad Khorsun wrote:
> [...]

>
> gbak:cannot commit index PK_XYZ
> gbak: ERROR:invalid database handle (no active connection)
> gbak: ERROR:action cancelled by trigger (3) to preserve data integrity
> gbak: ERROR: Cannot deactivate index used by a PRIMARY/UNIQUE constraint
> gbak:Exiting before completion due to errors
>
>
> Look at the firebird.log also, it should contain message(s):
>
> Failed to create worker attachment

Yes, it does. And additionally:

database /path/to/db shutdown

> Classic can't create additional worker attachments required to build
> indices as
> restoring database is in single-user shutdown mode. Thus it returns error
> and
> gbak seems not handle it properly. Register it at the tracker, please.

Done, #8263.

Thanks for sheding some light on the issue.

cheers
Tomasz