[Firebird-devel] [FB-Tracker] Created: (CORE-6021) Changing the state of a database trigger of type "On Commit" from inactive to active, the state change has no effect on other already opened connecti
Changing the state of a database trigger of type "On Commit" from inactive to active, the state change has no effect on other already opened connections. - Key: CORE-6021 URL: http://tracker.firebirdsql.org/browse/CORE-6021 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 3.0.4 Environment: Windows 10 x64, Firebird 3.0.3 SuperServer Reporter: Fernando Burciaga When having a database with a transaction commit database trigger and changing its state from inactive to active and vice versa the state is not changed in already opened connections. If there are other open connections, the commits done on these other connections do not execute the on transacttion commit trigger. Only new connections and the connection which activated the trigger execute it when commiting a transaction. With firebird version 2.5.8 the state change did affect other opened connections , but it doesn't with version 3.0.4. Table triggers do not have the same behavior, when activating a table trigger, other connections do execute the trigger correctly, even on version 3.0.4. Steps to reproduce: --- Create table in which the time of commit will be inserted by database trigger for every transaction commit --- CREATE TABLE COMMITED( COMMITED_TIME VARCHAR(50) ); --- create inactive on transaction commit trigger --- CREATE TRIGGER TR_ONCOMMIT_TIME INACTIVE ON TRANSACTION COMMIT AS BEGIN INSERT INTO COMMITED(COMMITED_TIME) VALUES (CURRENT_TIME); END; --- Open 2 connections at the same time for the database --- --- On connection 1 change the trigger status to ACTIVE --- ALTER TRIGGER TR_ONCOMMIT_TIME ACTIVE --- Start doing commits on both connections. Commits on connection 1 should start inserting into table COMMITED for every commit made, while connection 2 will not. --- This same test has different behavior on versions 2.5.8 and 3.0.4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-6020) Adding the ability to trace (using fbtrace) server access to system tables
Adding the ability to trace (using fbtrace) server access to system tables -- Key: CORE-6020 URL: http://tracker.firebirdsql.org/browse/CORE-6020 Project: Firebird Core Issue Type: Improvement Components: Engine, TRACEMGR Affects Versions: 4.0 Beta 1 Reporter: Rashid Abzalov Adding the ability to trace (using fbtrace) server access to system tables. Now the use of system tables are not visible when tracing. This feature will allow to "see" for what the time is spent in some ambiguous situations, such as, for example, CORE-5612. Also, this opportunity can be used not only by those who understand the source code of Firebird, but also by others. Now, without profiling skills, this cannot be done without contacting the Firebird developers. But it seems to me not rational to spend their time and professional skills on such issues, because less experienced users would have coped with it. On the other hand, the quality of the description of issues would be much better, because they would be able to independently gather the necessary information (with understanding of what is happening) before creating the incident. And in some cases, they would not even begin to create an issue, since would understand the problem or found the workaround yourself. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Start transaction from base transaction
On 3/1/19 4:50 PM, Dmitry Yemanov wrote: 01.03.2019 16:40, Adriano dos Santos Fernandes wrote: BTW it would be good to known if this pull request (with fb_info_tra_snapshot_number, SET TRANSACTION SNAPSHOT [ AT NUMBER ] and isc_tpb_at_snapshot_number) will go to master/v4. No problems from me. +1 Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-6019) Wire compression not working without MSVC 2010 runtime installation (FB4 Beta1)
Wire compression not working without MSVC 2010 runtime installation (FB4 Beta1) --- Key: CORE-6019 URL: http://tracker.firebirdsql.org/browse/CORE-6019 Project: Firebird Core Issue Type: Bug Affects Versions: 4.0 Beta 1 Environment: Clean, older Windows 7 and 10 versions, without updates Reporter: michalk1 Priority: Minor Wire compression (WireCompression = true in firebird.conf at client side ) is not working on some older Windows hosts (Win10 1803, Win7). A workaround is to download and install MSVC++ 2010 redistributable package. FB 4 installer contains VC2017 runtime, but wire compression (zlib1.dll ?) is probably still tied to the older version. Remote TCP connections fail instantly: isql -user sysdba -password masterkey testhost:employee Statement failed, SQLSTATE = 08006 Error reading data from the connection. Local TCP connect succeeds, but it's wire compression is not active, probably because compression fails sooner, already at the client side. Btw., I'm not sure whether Win XP are still supported, but my attempts to test FB4 Beta1 on them failed. First problem was in installation, which in it's final part displayed several error messages "This application has failed to start because api-ms-win-crt-runtime-l1-1-0.dll was not found.". But even when I fixed it by installation of another MSVC runtime (2015) and the installation completed, I was unable to connect from isql to employee database, FB log file says "Could not find acceptable ICU library". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-6018) Make it possible to start multiple transactions (possibly in different attachments) using the same initial transaction snapshot
Make it possible to start multiple transactions (possibly in different
attachments) using the same initial transaction snapshot
---
Key: CORE-6018
URL: http://tracker.firebirdsql.org/browse/CORE-6018
Project: Firebird Core
Issue Type: New Feature
Components: Engine
Reporter: Adriano dos Santos Fernandes
With this feature it's possible to create parallel (via different attachments)
processes reading consistent data from a database.
For example, a backup process may create multiple threads paralleling read data
from the database.
Also a web service may dispatch distributed sub services paralleling doing some
processing.
That is accomplished creating a transaction with SET TRANSACTION SNAPSHOT [ AT
NUMBER ] or isc_tpb_at_snapshot_number.
The from the first transaction may be obtained with
RDB$GET_CONTEXT('SYSTEM', 'SNAPSHOT_NUMBER') or transaction info call with
fb_info_tra_snapshot_number.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-6016) Rename RDB$GET_CONTEXT('SYSTEM', 'SNAPSHOT_CN') to RDB$GET_CONTEXT('SYSTEM', 'SNAPSHOT_NUMBER')
Rename RDB$GET_CONTEXT('SYSTEM', 'SNAPSHOT_CN') to RDB$GET_CONTEXT('SYSTEM',
'SNAPSHOT_NUMBER')
---
Key: CORE-6016
URL: http://tracker.firebirdsql.org/browse/CORE-6016
Project: Firebird Core
Issue Type: Task
Affects Versions: 4.0 Beta 1
Reporter: Adriano dos Santos Fernandes
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-6017) Add transaction info fb_info_tra_snapshot_number
Add transaction info fb_info_tra_snapshot_number
Key: CORE-6017
URL: http://tracker.firebirdsql.org/browse/CORE-6017
Project: Firebird Core
Issue Type: Improvement
Components: Engine
Reporter: Adriano dos Santos Fernandes
This info code returns the same as RDB$GET_CONTEXT('SYSTEM', 'SNAPSHOT_NUMBER')
running in snapshot transaction.
In READ COMMITTED READ CONSISTENCY transaction, different than
RDB$GET_CONTEXT('SYSTEM', 'SNAPSHOT_NUMBER'), fb_info_tra_snapshot_number will
return 0 as there is no request in this call.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Start transaction from base transaction
01.03.2019 16:40, Adriano dos Santos Fernandes wrote: BTW it would be good to known if this pull request (with fb_info_tra_snapshot_number, SET TRANSACTION SNAPSHOT [ AT NUMBER ] and isc_tpb_at_snapshot_number) will go to master/v4. No problems from me. Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Start transaction from base transaction
01.03.2019 15:40, Adriano dos Santos Fernandes wrote: On 01/03/2019 10:28, Vlad Khorsun wrote: ... BTW, what branch go you mean ? https://github.com/FirebirdSQL/firebird/pull/193 I'll change SNAPSHOT_CN name in different commit as it's already present in master. Understand now BTW it would be good to known if this pull request (with fb_info_tra_snapshot_number, SET TRANSACTION SNAPSHOT [ AT NUMBER ] and isc_tpb_at_snapshot_number) will go to master/v4. I vote to see it there. Regards, Vlad Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Start transaction from base transaction
On 01/03/2019 10:28, Vlad Khorsun wrote: > 01.03.2019 13:16, Adriano dos Santos Fernandes wrote: > >> I am assuming nobody objects and will implement the changes in the >> branch. > > No objection, just not forget to change syntax\constant names as was > agreed recently: > > --- > Which then I would go to isc_tpb_at_snapshot_number and SET TRANSACTION > SNAPSHOT [ AT NUMBER ] > --- > It's what I am telling replying to my own message quoting the previous message part. > BTW, what branch go you mean ? > https://github.com/FirebirdSQL/firebird/pull/193 I'll change SNAPSHOT_CN name in different commit as it's already present in master. BTW it would be good to known if this pull request (with fb_info_tra_snapshot_number, SET TRANSACTION SNAPSHOT [ AT NUMBER ] and isc_tpb_at_snapshot_number) will go to master/v4. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Start transaction from base transaction
On 25/02/2019 13:21, Adriano dos Santos Fernandes wrote: > Vlad is proposing the new info code to be named > fb_info_tra_snapshot_number. I have no problem with it, provided that > SNAPSHOT_CN is also renamed (with he seems to be open), but for what? > SNAPSHOT_NUMBER too? (I have no problem with that) > > So if we consistently call that number a "SNAPSHOT NUMBER" the path to > name the new TPB and SET TRANSACTION subclause becomes easy. > > Which then I would go to isc_tpb_at_snapshot_number and SET TRANSACTION > SNAPSHOT [ AT NUMBER ]. > > I am assuming nobody objects and will implement the changes in the branch. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] isc_database_info and current database user
I am just wondering if the requested feature is not already present. A quick test with isc_database_info, with SYSDBA and a normal user logged in shows: - SYSDBA connection: only SYSDBA appears to be returned. - User connection: only user name is returned. From the security viewpoint, only a System Administrator should be able to see a complete list of user names - which is true when using the MON$ATTACHMENTS pseudo table. It looks like isc_database_info could be broken in that it appears not to allow a SYSDBA to see this list. However, I would argue that MON$ATTACHMENTS should always be preferred hence this is not an issue. Otherwise, this whole thread seems to be an argument about whether it is easier to use isc_database_info (with the consequential difficulty of unpacking the information returned) or using the normal database API. If you don't like using low level APIs, then maybe a high level one like IBPP (C++), the PHP interbase API or IBX should be used as their whole point is to make common operations easy for the programmer and each, in their own way, makes "Select Current_User from RDB$DATABASE" a very simple operation to perform. On 27/02/2019 09:30, Kovalenko Dmitry wrote: Hello, Could anybody tell me – how I can get name of current user through isc_database_info API function? I see isc_info_user_names. But I want to get the only one name. Thanks, Dmitry Kovalenko. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] isc_database_info and current database user
On 01/03/2019 07:43, Dimitry Sibiryakov wrote: > 01.03.2019 11:32, Alex Peshkoff via Firebird-devel wrote: >> But if one writes some funny plugin which generates random names in >> authentication block - definitely yes :) > > They don't need to be random. I can imagine cases when they are a) > tied to a current node in a cluster because Firebird disallow > centralized authentication; b) temporary. > > In both cases the original node could use the same client username and have the same server result, so still does not need server CURRENT_USER, no? Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] isc_database_info and current database user
01.03.2019 11:32, Alex Peshkoff via Firebird-devel wrote: But if one writes some funny plugin which generates random names in authentication block - definitely yes :) They don't need to be random. I can imagine cases when they are a) tied to a current node in a cluster because Firebird disallow centralized authentication; b) temporary. -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] isc_database_info and current database user
On 3/1/19 1:25 PM, Dimitry Sibiryakov wrote: 01.03.2019 8:59, Alex Peshkoff via Firebird-devel wrote: Mapped user name has nothing to do with connection pool. Are you sure that there will be never a case when single client-side user name is mapped to different server-side users depending on some conditions unknown to client? As far as I know using just mapping & standard authentication plugins that's impossible. But if one writes some funny plugin which generates random names in authentication block - definitely yes :) Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] isc_database_info and current database user
01.03.2019 8:59, Alex Peshkoff via Firebird-devel wrote: Mapped user name has nothing to do with connection pool. Are you sure that there will be never a case when single client-side user name is mapped to different server-side users depending on some conditions unknown to client? -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-6015) Segfault when using expression index with complex expression
Segfault when using expression index with complex expression Key: CORE-6015 URL: http://tracker.firebirdsql.org/browse/CORE-6015 Project: Firebird Core Issue Type: Bug Affects Versions: 4.0 Beta 1, 3.0.4, 3.0.3, 2.5.8, 4.0 Alpha 1, 3.0.2, 2.5.7, 3.0.1, 2.5.6, 3.0.0, 4.0 Initial, 2.5.5, 2.5.4, 2.5.3 Update 1, 2.1.7, 2.5.3, 2.5.2 Update 1, 2.5.2, 2.5.1, 2.5.0 Reporter: Alexander Peshkov Nothing limits use of rather complex expression in the index. One can use selectable stored procedure to calculate that expression, and in that stored procedure one can select rows from the table on which expression index is created. During garbage collection of such index key value is calculated which causes expression evaluation, execution of SP and tabke scan - which in turn causes GC. I.e. we have unlimited recursion with obvious stack overflow and segfault. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
