Add limit for max value of -PARALLEL switch value when restoring a database

[tomaszdubiel18]

Currently gbak knows no limits when reading -par parameter and when a user tries to restore a database with gigantic value, (on purpose or by mistake - for example 16384) this will cause OOM killer on Linux. On Windows this caused whole OS to stop functioning and hard restart was required.
My proposition - if gbak is able to attach to firebird process (which has access to firebird.conf) just by using services manager, then why not to use it exactly to read MaxParallelWorkers? It seems an ideal parameter to restrict max parallel workers. Why does it have to be limited for parallel operations apart from gbak?
Best regards.

[hvlad]

My proposition - if gbak is able to attach to firebird process (which has access to firebird.conf) just by using services manager, then why not to use it exactly to read MaxParallelWorkers?

It is question, not proposition. Make it clear, please.

Why does it have to be limited for parallel operations apart from gbak?

Because MaxParallelWorkers belongs to the engine, not to the utilities.
firebird.conf is used by server components, such as engine, dispatcher, network server, etc.
But not by the utilities. And this will not be changed.

[aafemt]

Does something prevent gbak from getting MaxParallelWorkers from MON$CONFIG and adjust own settings accordingly?

[hvlad]

Remember, gbak can run on another host with another resources than Firebird server.
Why the hell gbak should depend on server setting in this regard ?
Just because you can't offer reasonable value for gbak's own limit ?
I can agree that in service mode it could make sense, but not in the standalone.

[mrotteveel]

I'm not entirely sure it would make sense to have gbak through services manager use MaxParallelWorkers either, as that would be inconsistent with running the gbak utility directly. And having the gbak utility read it from firebird.conf would be problematic, as then running it standalone (i.e. no firebird.conf) would apply - as it is right now - MaxParallelWorkers = 1, disabling parallelism. Having two different defaults wouldn't be desirable either.

Personally, I'd say having some hardcoded upper limit for the number of connections gbak creates, like 64 (current maximum for MaxParallelWorkers), or maybe using min(CPU-count + 1, 64) or min(CPU-count + 2, 64) should be sufficient to prevent this footgun.

[mrotteveel]

And, yes, having gbak use the client-side CPU count to decide its maximum might not be optimal, but it should be "good enough".

Or use a lower upper limit than the 64 I proposed in my previous comment ;) I guess there are diminished returns at some point, even if the server is a beast with a lot of CPUs.

[tomaszdubiel18]

Remember, gbak can run on another host with another resources than Firebird server. Why the hell gbak should depend on server setting in this regard ? Just because you can't offer reasonable value for gbak's own limit ? I can agree that in service mode it could make sense, but not in the standalone.

So is it a problem to depend on client resources when gbak runs on the other host and to depend on server resources when gbak runs on server?

[aafemt]

having gbak use the client-side CPU count to decide its maximum might not be optimal

That's why I suggested to use server-side configured limit.