Deprecation

[Dmitry Yemanov]

All,

We've officially declared deprecated:

v3: legacy UDFs and GSEC utility

v4: FileSystemCacheThreshold config option, LONG FLOAT data type, QLI
utility, Dialect 1

Only QLI from this list was actually removed (in v5).

What are our plans about the others? Should we plan some cleanup for v6?



Dmitry

[Dimitry Sibiryakov]

Dmitry Yemanov wrote 11.11.2023 11:37:
> We've officially declared deprecated:
>
> v3: legacy UDFs and GSEC utility
>
> v4: FileSystemCacheThreshold config option, LONG FLOAT data type, QLI utility,
> Dialect 1
>

> What are our plans about the others? Should we plan some cleanup for v6?

I would object against deprecation of gsec. IMHO, auth plugins should be
expanded instead to perform client-side part of user management which is the
idea behind zero-reveal auth protocols (SRP).

--
WBR, SD.

[Omacht András]

Hi,

please support dialect1 until there is a satisfactory solution to the rounding problem.

https://github.com/FirebirdSQL/firebird/issues/6928
https://github.com/FirebirdSQL/firebird/issues/6980

For us, it is mission impossible to switch to D3 if the current operation remains.

Thanks!

András

--
You received this message because you are subscribed to the Google Groups "firebird-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-deve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebird-devel/469ae7e0-c955-ddbc-281e-9a216c610713%40yandex.ru.

[Mark Rotteveel]

On 11-11-2023 11:57, 'Dimitry Sibiryakov' via firebird-devel wrote:
> Dmitry Yemanov wrote 11.11.2023 11:37:
>> We've officially declared deprecated:
>>
>> v3: legacy UDFs and GSEC utility
>>
>> v4: FileSystemCacheThreshold config option, LONG FLOAT data type, QLI
>> utility, Dialect 1
>>
>> What are our plans about the others? Should we plan some cleanup for v6?
>
>   I would object against deprecation of gsec.

GSEC was deprecated with Firebird 3.0, you're too late to raise an
objection IMHO.

Mark
--
Mark Rotteveel

[Денис Симонов]

I think it’s safe to remove gsec as a utility (and let it remain in services) and the FileSystemCacheThreshold parameter. The functionality of gsec is completely overlapped by SQL.

No matter how much you would like to delete 1 dialect, it is better not to do this for now. There are no alternatives provided in terms of calculation rules, and therefore many continue to use 1 dialect.

It’s better to hold off on UDF too. There are some simple UDFs that are significantly faster than a UDR, since the overhead of calling a UDF that does nothing is an order of magnitude less than the overhead of the same UDR. And UDFs do quite simple things in some cases. If we can somehow reduce these overheads so that they are comparable, then we can say that UDFs are completely replaceable with UDRs.

суббота, 11 ноября 2023 г. в 14:21:39 UTC+3, Mark Rotteveel:

[Mark Rotteveel]

On 13-11-2023 11:28, Денис Симонов wrote:
> I think it’s safe to remove gsec as a utility (and let it remain in
> services) and the FileSystemCacheThreshold parameter. The functionality
> of gsec is completely overlapped by SQL.

There is no need to retain the service either.

> No matter how much you would like to delete 1 dialect, it is better not
> to do this for now. There are no alternatives provided in terms of
> calculation rules, and therefore many continue to use 1 dialect.

Dialect 1 has been deprecated for 24 years already since _before_
Firebird existed. And there are alternatives for the calculations, like
using DECFLOAT, or using DOUBLE PRECISION for intermediate calculations.

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

'Mark Rotteveel' via firebird-devel wrote 13.11.2023 11:34:
>> I think it’s safe to remove gsec as a utility (and let it remain in services)
>> and the FileSystemCacheThreshold parameter. The functionality of gsec is
>> completely overlapped by SQL.
>
> There is no need to retain the service either.

User management using SQL is insecure. Password must not travel through wire
ever.

--
WBR, SD.

[Mark Rotteveel]

The same happens with user management via gsec/services remotely, so
that is not an argument not to remove gsec or the user service.

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

'Mark Rotteveel' via firebird-devel wrote 13.11.2023 11:37:
>>
>>    User management using SQL is insecure. Password must not travel through
>> wire ever.
>
> The same happens with user management via gsec/services remotely, so that is not
> an argument not to remove gsec or the user service.

Yes, but they can be fixed only while not removed.

--
WBR, SD.

[Paul Reeves]

I think we should continue to encourage users to migrate their UDFs to UDRs
but I don't think it is a good idea to remove support for UDFs.


Paul
--
Paul Reeves
http://www.ibphoenix.com
Supporting users of Firebird

[Dmitry Yemanov]

All,

Thanks for feedback. So far it seems that gsec may die, as well as
deprecated config option(s).

Re. UDFs -- keep them for a while. Attempt to reduce the UDR call
overhead. Encourage migration to UDRs.

Re. Dialect 1 -- I'd suggest to revisit and address (or declare as won't
fix) the remaining issues in v6 and encourage migration to dialect 3.
Then probably remove dialect 1 in v7.

Objections anyone?


Dmitry

[Alex Peshkoff]

On 11/13/23 21:16, Dmitry Yemanov wrote:
> All,
>
> Thanks for feedback. So far it seems that gsec may die
>

gsec-related services and isc_add/modify/delete_user functions should
also be removed

[Dimitry Sibiryakov]

Alex Peshkoff wrote 22.11.2023 14:24:
> gsec-related services and isc_add/modify/delete_user functions should also be
> removed

It will break a lot of applications.

--
WBR, SD.

[Денис Симонов]

I don't see anything wrong with this. Managing users through SQL is a much more powerful and at the same time simpler method. Most of those who migrated to Firebird 3+ have already done this in their applications. And those who haven’t done so will have a reason to finally start managing users correctly.

среда, 22 ноября 2023 г. в 16:25:40 UTC+3, Dimitry Sibiryakov:

[Dimitry Sibiryakov]

Денис Симонов wrote 22.11.2023 15:39:
> I don't see anything wrong with this. Managing users through SQL is a much more
> powerful and at the same time simpler method.

It is simpler for a barehand DBA but for an application developer there is no
difference between calling isc_dsql_exec_immed() and isc_add_user().

> Most of those who migrated to Firebird 3+ have already done this in their applications. And those who haven’t done so will have a reason to finally start managing users correctly.

I wouldn't consider passing plain password through wire as a "correct way".
At least the query should accept a plugin-dependend auth data instead (such as
salt+verifier for SRP).

--
WBR, SD.

[Alex Peshkoff]

On 11/22/23 17:48, 'Dimitry Sibiryakov' via firebird-devel wrote:
> Денис Симонов wrote 22.11.2023 15:39:
>> I don't see anything wrong with this. Managing users through SQL is a
>> much more powerful and at the same time simpler method.
>
>   It is simpler for a barehand DBA but for an application developer
> there is no difference between calling isc_dsql_exec_immed() and
> isc_add_user().
>

For me main problem with mentioned methods is missing support for
multiple security databases. And no idea how to expand it with plain
struct as parameter.

>> Most of those who migrated to Firebird 3+ have already done this in
>> their applications. And those who haven’t done so will have a reason
>> to finally start managing users correctly.
>
>   I wouldn't consider passing plain password through wire as a
> "correct way".

Wire is encrypted by default.

> At least the query should accept a plugin-dependend auth data instead
> (such as salt+verifier for SRP).
>

Do you suggest to preparse SQL on client?

[Dimitry Sibiryakov]

Alex Peshkoff wrote 22.11.2023 18:35:
>
> For me main problem with mentioned methods is missing support for multiple security databases. And no idea how to expand it with plain struct as parameter.

But for services it is not a problem: expected_db we have there.
For plain struct we can use the same way MS uses: field protocol can work as
version tag which allow to detect version of the structure.

> Do you suggest to preparse SQL on client?

No, I suggest to give users way to provide more data in the query, not only
"password" as it is done with tags now. Something like this:

create user abc using plugin srp salt 0x'1234567889' verifier 0x'12345678'
create user abc using legacy_usermanager hash 0x'123456789'

DSQL can provide set of arrived parameters to manager plugin as is and let it
decide what to do with them.

--
WBR, SD.

[Alex Peshkoff]

On 11/22/23 20:47, 'Dimitry Sibiryakov' via firebird-devel wrote:
> Alex Peshkoff wrote 22.11.2023 18:35:
>>
>> For me main problem with mentioned methods is missing support for
>> multiple security databases. And no idea how to expand it with plain
>> struct as parameter.
>
>   But for services it is not a problem: expected_db we have there.

expected_db currently works only at services manager level (what DB to
use for login) and is not passed to utilities
certainly than can be changed - but where do we pass it if gsec is removed?

> For plain struct we can use the same way MS uses: field protocol can
> work as version tag which allow to detect version of the structure.

use of protocol field as version number is defintely dirty hack
imagine five years later we need new connection protocol (using quantum
entanglement) - what to do then?

>
>> Do you suggest to preparse SQL on client?
>
>   No, I suggest to give users way to provide more data in the query,
> not only "password" as it is done with tags now. Something like this:
>
>   create user abc using plugin srp salt 0x'1234567889' verifier
> 0x'12345678'
>   create user abc using legacy_usermanager hash 0x'123456789'
>
>   DSQL can provide set of arrived parameters to manager plugin as is
> and let it decide what to do with them.
>

Suppose that some other form of SQL syntax should be preferred in order
to make solution generic, but yes - this can work.
What I do not understand is what for it's needed.
- If we use SRP we have encrypted wire.
- If we use legacy - it does not matter how we send password.
- In general - if we use some reliable and secure authentication method
it should produce wire crypt key, and wire should be encrypted.

I.e. I do not see a reason to implement this suggestion.

[Dimitry Sibiryakov]

Alex Peshkoff wrote 23.11.2023 12:11:
>>   But for services it is not a problem: expected_db we have there.
>
> expected_db currently works only at services manager level (what DB to use for
> login) and is not passed to utilities
> certainly than can be changed - but where do we pass it if gsec is removed?

To a service provider may be?.. It was already discussed years ago that
services must have its own providers and not to be a part of engine.

>> For plain struct we can use the same way MS uses: field protocol can work as
>> version tag which allow to detect version of the structure.
>
> use of protocol field as version number is defintely dirty hack
> imagine five years later we need new connection protocol (using quantum
> entanglement) - what to do then?

As an idea: protocol version "custom" requires field "server" to be a full
connection string to expected DB. In this case real connection protocol is the
same as if connection to this db really established: through the list of providers.

> What I do not understand is what for it's needed.
> - If we use SRP we have encrypted wire.
> - If we use legacy - it does not matter how we send password.
> - In general - if we use some reliable and secure authentication method it should produce wire crypt key, and wire should be encrypted.

Imagine a custom user auth plugin and manager, using LDAP and fingerprints or
other biometrics for authentication. How could it work using current SQL syntax?

--
WBR, SD.

[Mark Rotteveel]

On 23-11-2023 12:28, 'Dimitry Sibiryakov' via firebird-devel wrote:
>   Imagine a custom user auth plugin and manager, using LDAP and
> fingerprints or other biometrics for authentication. How could it work
> using current SQL syntax?

They could work similar as the WinSspi provider, and not even require a
user in the database. Or if they do want a user, they may not need to
store authentication info, and instead rely on a different authority
(e.g. LDAP/Kerberos) to verify the credentials.

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

'Mark Rotteveel' via firebird-devel wrote 23.11.2023 12:32:
> They could work similar as the WinSspi provider, and not even require a user in
> the database.

I.e. don't work at all. Current WinSspi auth plugin has no corresponding user
manager.

> Or if they do want a user, they may not need to store authentication info, and instead rely on a different authority (e.g. LDAP/Kerberos) to verify the credentials.

But what if it WANT to be able to create new users or alter old ones?
You declared that using SQL is the preferable way to manage users and
external utilities must die but it is exactly what WinSspi has to do: rely on
external utilities for user management because there is no SQL way for that.

--
WBR, SD.

[Adriano dos Santos Fernandes]

When one integrates an external authentication method to a database, I
doubt it's desired that password (or other info) changes is managed from
the database.


Adriano

[Mark Rotteveel]

The whole point of WinSspi is to use OS authentication mechanisms, so
you don't have to manage them in Firebird.

But, yes, I grant you that if you want certain custom mechanisms and
have a user manager that needs to store additional data, you may need to
contort things a bit by either using the tags, or encoding things in the
password in a plugin specific format, and having some extensible format
similar to TAGS might be useful.

That said, personally I'd sooner expect a new plugin similar to WinSspi,
e.g. using GSS-API, so that not only Windows authentication can be
supported, but also Kerberos and other authentication services
supporting GSS API.

Mark
--
Mark Rotteveel

[Mark Rotteveel]

On 23-11-2023 12:44, Adriano dos Santos Fernandes wrote:
> When one integrates an external authentication method to a database, I
> doubt it's desired that password (or other info) changes is managed from
> the database.

The only thing I can think of is that maybe you want to be able to
explicitly identify the users you want to authenticate, instead of
relying on groups and/or mappings to authorize users from the external
authentication method.

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

Adriano dos Santos Fernandes wrote 23.11.2023 12:44:
> When one integrates an external authentication method to a database, I
> doubt it's desired that password (or other info) changes is managed from
> the database.

Why? Is there any reason not to use DBMS methods for managing user accounts
used to attach to databases at least for consistency sake?

--
WBR, SD.

[Mark Rotteveel]

Because those accounts are managed externally, e.g. in Active Directory.

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

'Mark Rotteveel' via firebird-devel wrote 23.11.2023 12:50:
>>    Why? Is there any reason not to use DBMS methods for managing user accounts
>> used to attach to databases at least for consistency sake?
>
> Because those accounts are managed externally, e.g. in Active Directory.

So what? How does it prevent them from being managed with SQL as well?

--
WBR, SD.

[Adriano dos Santos Fernandes]

What others products that integrates with such external auth sources
manage users?

I guess, none.


Adriano

[Mark Rotteveel]

The whole point of such solutions is that there is a _single_ way of
administering users, and the administration of those users is generally
entirely separate from DBAs or people to do with databases, with their
own rules and requirements.

Having a backdoor through the database to alter user information would
generally be entirely incompatible with those requirements.

Do you have any experience in companies with 100+ or 1000+ users?

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

Adriano dos Santos Fernandes wrote 23.11.2023 12:57:
> What others products that integrates with such external auth sources
> manage users?
>
> I guess, none.

I repeat: so what? How does it prevent Firebird from being a pioneer?

> The whole point of such solutions is that there is a _single_ way of administering users, and the administration of those users is generally entirely separate from DBAs or people to do with databases, with their own rules and requirements.

Ok I see your objections against external authentication authorities, but
once again: say I want Firebird users to be authenticated by fingerprints and
keep this data in security db. How can I manage it via SQL? Only with encoding
hacks and abuse of tags, exactly as you said. Not good, IMHO.
That's why I object against deprecation of security services and API in favor
of SQL-only management.

> Do you have any experience in companies with 100+ or 1000+ users?

Yes.

--
WBR, SD.

[Mark Rotteveel]

On 23-11-2023 13:05, 'Dimitry Sibiryakov' via firebird-devel wrote:
> Adriano dos Santos Fernandes wrote 23.11.2023 12:57:
>> What others products that integrates with such external auth sources
>> manage users?
>>
>> I guess, none.
>
>   I repeat: so what? How does it prevent Firebird from being a pioneer?

Because - I'm possibly over-generalizing here - there is no point in
doing that. It will either not get used, and it might even actively
hinder adoption exactly because companies wanting such solutions do not
want external tools to mess with the user information in that external
auth source.

>> The whole point of such solutions is that there is a _single_ way of
>> administering users, and the administration of those users is
>> generally entirely separate from DBAs or people to do with databases,
>> with their own rules and requirements.
>
>   Ok I see your objections against external authentication authorities,

I have no objection against external authentication authorities, I have
an objection against modifying those authorities from SQL.

> but once again: say I want Firebird users to be authenticated by
> fingerprints and keep this data in security db. How can I manage it via
> SQL? Only with encoding hacks and abuse of tags, exactly as you said.
> Not good, IMHO.

As I said, there is some merit in adding something extensible.

>   That's why I object against deprecation of security services and API
> in favor of SQL-only management.

And how would the gsec service API help you in that?

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

'Mark Rotteveel' via firebird-devel wrote 23.11.2023 13:15:
>
> As I said, there is some merit in adding something extensible.
>
>>    That's why I object against deprecation of security services and API in
>> favor of SQL-only management.
>
> And how would the gsec service API help you in that?

gsec and services API are different things you know. Even if now later is
using former.
And Services API is extensible so there is no point in adding something new
removing something old that already serves its new purposes.

--
WBR, SD.

[Mark Rotteveel]

Gsec is basically a thin layer on top of the services API for user
management, and neither offer what you want right now either.

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

'Mark Rotteveel' via firebird-devel wrote 23.11.2023 13:24:
> Gsec is basically a thin layer on top of the services API for user management,
> and neither offer what you want right now either.

It is not quite so. gsec was created to use old GDS/ISC API for user
management and modifying it for Services API was quick and incomplete so gsec
uses only a little part of Services API functionality.

--
WBR, SD.

[Alex Peshkoff]

On 11/23/23 15:15, 'Mark Rotteveel' via firebird-devel wrote:
> On 23-11-2023 13:05, 'Dimitry Sibiryakov' via firebird-devel wrote:
>> Adriano dos Santos Fernandes wrote 23.11.2023 12:57:
>>> What others products that integrates with such external auth sources
>>> manage users?
>>>
>>> I guess, none.
>>
>>    I repeat: so what? How does it prevent Firebird from being a pioneer?
>
> Because - I'm possibly over-generalizing here - there is no point in
> doing that. It will either not get used, and it might even actively
> hinder adoption exactly because companies wanting such solutions do
> not want external tools to mess with the user information in that
> external auth source.

Let me add 2c here - let's try to make Firebird a pioneer in something
useful instead managing 3-d party authorities from SQL.

>> but once again: say I want Firebird users to be authenticated by
>> fingerprints and keep this data in security db. How can I manage it
>> via SQL? Only with encoding hacks and abuse of tags, exactly as you
>> said. Not good, IMHO.
>
> As I said, there is some merit in adding something extensible.
>
>>    That's why I object against deprecation of security services and
>> API in favor of SQL-only management.
>
> And how would the gsec service API help you in that?
>

Mark, I 100% agree with you - when we will need a way to manage
fingerprints in our plugins we should better add appropriate support in
SQL. Next, suppose everyone agree that such extension of SQL is possible
(in minimum case tags already make it possible). So let's worry about
such extension when we really need it. Last but not least - that time we
will definitely better understand what we need.

[Денис Симонов]

When we want to manage something that is not provided by the Firebird SQL syntax, then there is an excellent solution - External UDR.

четверг, 23 ноября 2023 г. в 16:10:11 UTC+3, Alex Peshkoff:

[Dimitry Sibiryakov]

BTW, about deprecation: multifile databases were deprecated quite long ago
and nbackup doesn't support them. Isn't it time to clean this feature out
completely?

--
WBR, SD.

[Dmitry Yemanov]

+1


Dmitry

[Adriano dos Santos Fernandes]

On 13/11/2023 07:28, Денис Симонов wrote:
> It’s better to hold off on UDF too. There are some simple UDFs that are
> significantly faster than a UDR, since the overhead of calling a UDF
> that does nothing is an order of magnitude less than the overhead of the
> same UDR. And UDFs do quite simple things in some cases. If we can
> somehow reduce these overheads so that they are comparable, then we can
> say that UDFs are completely replaceable with UDRs.

I did this simple test in master:

-----
DECLARE EXTERNAL FUNCTION div_udf
INTEGER, INTEGER
RETURNS DOUBLE PRECISION BY VALUE
ENTRY_POINT 'IB_UDF_div' MODULE_NAME 'ib_udf';

create function div_udr (
n1 integer,
n2 integer
) returns double precision
external name 'udf_compat!UC_div'
engine udr;

set autoterm on;
set stats on;


-- 8.2 seconds
execute block
as
declare n integer = 5000000;
declare x integer;
begin
while (n > 0) do
begin
n = n - 1;
x = div_udf(3, 2);
end
end;


-- 4.5 seconds
execute block
as
declare n integer = 5000000;
declare x integer;
begin
while (n > 0) do
begin
n = n - 1;
x = div_udr(3, 2);
end
end;
-----

ib_udf was built in v3 and copied.

AFAIK, both functions are compatible.

All release build.

UDR was much faster.

So did you have an example of simple UDF that is significantly faster
than UDR?


Adriano

[Karol Bieniaszewski]

Hi

 

Can you share this udr to test? Have it all nescessery setup metchods to be full secure compared to udf?

 

Regards,

Karol Bieniaszewski

--

You received this message because you are subscribed to the Google Groups "firebird-devel" group.

To unsubscribe from this group and stop receiving emails from it, send an email to firebird-deve...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebird-devel/9e0fba6f-b44d-4e81-a5b5-7bd757b179a7%40gmail.com.

 

[Mark Rotteveel]

On 10/01/2024 15:14, Karol Bieniaszewski wrote:
> Can you share this udr to test? Have it all nescessery setup metchods to
> be full secure compared to udf?

What does "all nescessery setup metchods to be full secure compared to
udf" mean?

Mark
--
Mark Rotteveel

[Karol Bieniaszewski]

Udf is marked as obsolete because it is not secure. UDR is just as dangerous if you don't define vetting methods.

And these are the methods I'm talking about ;-)

 

Regards,

Karol Bieniaszewski

--

You received this message because you are subscribed to the Google Groups "firebird-devel" group.

To unsubscribe from this group and stop receiving emails from it, send an email to firebird-deve...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebird-devel/6f5d3a21-d503-4595-9856-4820af203f03%40lawinegevaar.nl.

 

[Adriano dos Santos Fernandes]

Em qua., 10 de jan. de 2024 11:41, Karol Bieniaszewski <livius...@poczta.onet.pl> escreveu:

Udf is marked as obsolete because it is not secure. UDR is just as dangerous if you don't define vetting methods.

And these are the methods I'm talking about ;-)

UDR is native code as well and may be dangerous if bad coded.

UDF may be dangerous even if well coded, as a wrong DECLARE may cause the problem.

About my test, the UDR is present in the Firebird core repository.

Adriano

[Vlad Khorsun]

10.01.2024 12:44, Adriano dos Santos Fernandes:

I see different results:
UDF : 1734 ms
UDR : 4469 ms

Profiler shows that most time is spend in FUN_evaluate for UDF case, and
in EXE_send\EXE_receive for the UDR case. And it is fully expected.


Regards,
Vlad

[Vlad Khorsun]

>   I see different results:
> UDF : 1734 ms
> UDR : 4469 ms
>
>   Profiler shows that most time is spend in FUN_evaluate for UDF case, and
> in EXE_send\EXE_receive for the UDR case. And it is fully expected.

Correction: EXE_start, not EXE_send

Regards,
Vlad

[Adriano dos Santos Fernandes]

Em qua., 10 de jan. de 2024 12:48, Vlad Khorsun <fbv...@gmail.com> escreveu:

   I see different results:
UDF : 1734 ms
UDR : 4469 ms

My test was with Ryzen 9 and your is in the line I previously saw on Core i7.

What's your?

Adriano

[Vlad Khorsun]

10.01.2024 17:57, Adriano dos Santos Fernandes:

> Em qua., 10 de jan. de 2024 12:48, Vlad Khorsun <fbv...@gmail.com <mailto:fbv...@gmail.com>> escreveu:
>
>
>    I see different results:
> UDF : 1734 ms
> UDR : 4469 ms
>
>
> My test was with Ryzen 9 and your is in the line I previously saw on Core i7.
>
> What's your?

Yes, Core i7. But I don't think it matters too much.

Regards,
Vlad

[Dmitry Yemanov]

10.01.2024 18:48, Vlad Khorsun wrote:
>
> I see different results:
> UDF : 1734 ms
> UDR : 4469 ms

For me, elapsed time from ISQL:

UDF : 12.5s
UDR : 7.5s

Tested with v5 release, UDF from v3 release, employee database.
AMD Ryzen 7.


Dmitry

[Karol Bieniaszewski]

> UDR is native code as well and may be dangerous if bad coded.

>UDF may be dangerous even if well coded, as a wrong DECLARE may cause the problem.

 

Yes, that was my point.

 

> About my test, the UDR is present in the Firebird core repository.

 

Where, can you put a link? I will test then on I7, Xenon..

 

Regards,

Karol Bieniaszewski

 

Od: Adriano dos Santos Fernandes

Wysłano: środa, 10 stycznia 2024 16:14
Do: firebir...@googlegroups.com
Temat: Re: ODP: [firebird-devel] UDF vs UDR speed (was Re: Deprecation)

 

Em qua., 10 de jan. de 2024 11:41, Karol Bieniaszewski <livius...@poczta.onet.pl> escreveu:

--

You received this message because you are subscribed to the Google Groups "firebird-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-deve...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebird-devel/CALko8OSp9MmEZfD23Mwh3DUsGHWF-fb9_E2LNA_xFebLwNPJrw%40mail.gmail.com.

 

[Mark Rotteveel]

On 10/01/2024 18:06, Karol Bieniaszewski wrote:
> > UDR is native code as well and may be dangerous if bad coded.
>
> >UDF may be dangerous even if well coded, as a wrong DECLARE may cause
> the problem.
>
> Yes, that was my point.

You seem to be missing the point that UDFs are more dangerous than UDR
because wrong declaration of a correctly coded UDF can compromise your
system, while UDRs don't have that issue, while you seem to assume they
are equally dangerous.

> > About my test, the UDR is present in the Firebird core repository.
>
> Where, can you put a link? I will test then on I7, Xenon..

The udf_compat is included by default since Firebird 4 (see plugins/udr
in your Firebird install, and the Firebird 4 release notes[1]).

[1]:
https://firebirdsql.org/file/documentation/release_notes/html/en/4_0/rlsnotes40.html#rnfb40-compat-udfs
--
Mark Rotteveel

[Vlad Khorsun]

10.01.2024 18:23, Dmitry Yemanov:

Linux ? Could profile it ?

Regards,
Vlad

[Dmitry Yemanov]

10.01.2024 20:06, Karol Bieniaszewski wrote:

> Where, can you put a link? I will test then on I7, Xenon..

All you need to run this test is to copy the UDF subdirectory of FB3 to
FB5 and then set up UdfAccess = Restrict UDF. That's all.


Dmitry

[Dmitry Yemanov]

10.01.2024 20:14, Vlad Khorsun wrote:
>
>> 10.01.2024 18:48, Vlad Khorsun wrote:
>>>
>>> I see different results:
>>> UDF : 1734 ms
>>> UDR : 4469 ms
>>
>> For me, elapsed time from ISQL:
>>
>> UDF : 12.5s
>> UDR : 7.5s
>>
>> Tested with v5 release, UDF from v3 release, employee database.
>> AMD Ryzen 7.
>
>   Linux ? Could profile it ?

Yes, Linux. syncSignalsSet / syncSignalsReset are a bottleneck.

Without them the times are:

UDF : 3.5s
UDR : 7.5s


Dmitry

[Karol Bieniaszewski]

>> You seem to be missing the point that UDFs are more dangerous than UDR

>> because wrong declaration of a correctly coded UDF can compromise your

>> system, while UDRs don't have that issue, while you seem to assume they

>> are equally dangerous.

 

Udr is same dangerous if written minimal code without proper setup, parameters types check etc.

 

>> The udf_compat is included by default since Firebird 4 (see plugins/udr

>> in your Firebird install, and the Firebird 4 release notes[1]).

 

I did not used udf_compat previously as built in functions was enough, that the reason i have thinked that Adriano written something new to provide test 😉

 

Regards,

Karol Bieniaszewski

 

Od: 'Mark Rotteveel' via firebird-devel

Wysłano: środa, 10 stycznia 2024 18:13
Do: firebir...@googlegroups.com

--

You received this message because you are subscribed to the Google Groups "firebird-devel" group.

To unsubscribe from this group and stop receiving emails from it, send an email to firebird-deve...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebird-devel/f7eaa4bd-7270-4bd8-b48d-0790607aa994%40lawinegevaar.nl.

 

[Vlad Khorsun]

10.01.2024 19:48, Dmitry Yemanov:

Great. BTW, it could be checked out by setting BugCheckAbort = 1, AFAIU.

As for syncSignalsSet / syncSignalsReset stuff. Looks like it is not ready to
handle recursive (nested) calls ? UDR could run query in the same database, thus
such case could happen, correct ? Also, it seems possible to eliminate all but one
call of sigaction() during current API call:
- set handler when enter engine, reset on exit,
- syncSignalsSet and syncSignalsReset will just set thread-local pointer,
- organize pointers to sigjmp_buf into thread-local list or stack,
- longjmpSigHandler should use most recently saved pointer to sigjmp_buf,
- remove syncEnterMutex and syncEnterCounter as not needed anymore.

Probably I missed some details of sigaction() mechanics that makes above wrong, though...

Regards,
Vlad