[Firebird-devel] [FB-Tracker] Created: (CORE-5925) bad parameters on attach or create database CHARACTER SET WIN1250 is not defined
bad parameters on attach or create database CHARACTER SET WIN1250 is not defined Key: CORE-5925 URL: http://tracker.firebirdsql.org/browse/CORE-5925 Project: Firebird Core Issue Type: Bug Components: Charsets/Collation Affects Versions: 2.5.8 Environment: CentOS 7.5 Reporter: Pawel Kubiczek After updating Firebird from version firebird-superserver-2.5.7.27050.0-1.el7.x86_64 to firebird-superserver-2.5.8.27089.0-1.el7.x86_64 application failed to start with error message: "bad parameters on attach or create database CHARACTER SET WIN1250 is not defined". I could NOT fine any related issue on the google with similar description. After restoring Firebird from backup application works fine. But on other CentOS server I do update again and finally found a solution. When I take the a /usr/lib64/firebird/intl/fbintl from version 2.5.7 and put it (replaced it) in version 2.5.8 application start working again on 2.5.8. alfa /usr/lib64/firebird/intl # ll total 2592 -rwxr-xr-x. 1 root root 884616 Aug 31 12:10 fbintl lrwxrwxrwx. 1 root root 25 Sep 25 22:28 fbintl.conf -> /etc/firebird/fbintl.conf -rwxr-xr-x. 1 root root 884496 Feb 21 2017 fbintl.ORIG.2.5.7 -rwxr-xr-x. 1 root root 884616 Aug 31 12:10 fbintl.ORIG.2.5.8 alfa /usr/lib64/firebird/intl # cp -p fbintl.ORIG.2.5.7 fbintl cp: overwrite 'fbintl'? y alfa /usr/lib64/firebird/intl # ll total 2592 -rwxr-xr-x. 1 root root 884496 Feb 21 2017 fbintl lrwxrwxrwx. 1 root root 25 Sep 25 22:28 fbintl.conf -> /etc/firebird/fbintl.conf -rwxr-xr-x. 1 root root 884496 Feb 21 2017 fbintl.ORIG.2.5.7 -rwxr-xr-x. 1 root root 884616 Aug 31 12:10 fbintl.ORIG.2.5.8 alfa /usr/lib64/firebird/intl # systemctl restart firebird-superserver.service -- 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] ODP: ODP: CORE-5921
25.09.2018 22:37, Karol Bieniaszewski wrote: Hi Vlad, Maybe you should go first to the end of may email (quite long – sorry please be patient) Not so long ;) I suppose that i misunderstand names and meaining. This is the commit number of currently used snapshot, if present. Non-RC transactions create snapshot at own start and SNAPSHOT_CN is the CN of that snapshot. RCRC transactions create snapshot when user query execution starts. Old style RC transactions doesn't create snapshots. Maybe i still do not know what does „snapshot” in name SNAPSHOT_CN mean? Is this CN of last commited snapshot transaction (excluding any read commited) or what? If this is last committed snapshot transaction and block progress until next snapshot is commited then it is not so usefull, Because if read commited transaction change something i will not see changes in delta until new snapshot transaction will be commited. But maybe my understand of SNAPSHOT_CN is wrong? If my understanding is ok – then i can fix this by starting empty snapshot transaction and commit it or do any select in RC transaction before got delta. Then i can run my interesting query with delta fetch. But maybe GLOBAL_CN is better here and fix all my maining issues. Seems you understanding (or my explanations) is not complete. Database have new special counter (Global Commit Number) which incremented when any transaction commits. This is GLOBAL_CN. When any transaction commits, engine increments GLOBAL_CN and assign its value to the transaction. No two committed transactions could have the same CN assigned. Database snapshot is identified by value of GLOBAL_CN at the moment when snapshot was created. We name this snapshot id as Snapshot CN. When SNAPSHOT or CONCURRENCY transaction is starts, it creats own database snapshot. I.e. this snapshot have Snapshot CN equal to the GLOBAL_CN at the time when transaction started. This transaction snapshot is current snapshot for all the statements running within this transaction. When any kind of READ COMMITTED transaction started - it doesn't create any snapshots. When some statement start execution within READ COMMITTED READ CONSISTENCY (RCRC) transaction, it creates own database snapshot and makes it current until statement execution finished. Then this statement-level snapshot is released. Every new top-level statement creates its own database snapshot. Statements, running within READ COMMITTED RECORD VERSION and\or READ COMMITTED NO RECORD VERSION transaction doesn't create database snapshot. Context variable SNAPSHOT_CN returns value of *current* snapshot, if it is exists. So, it could be transaction-level snapshot (if statement running within SNAPSHOT or CONCURRENCY transaction), or statement-level snapshot (if statement running within RCRC transaction). Hmm... probably you want here SELECT * FROM NAMES WHERE RDB$GET_TRANSACTION_CN(RDB$RECORD_VERSION) >= :lastCN If this call to RDB$GET_TRANSACTION_CN will be efficient as separate request per record then yes If not then virtual table will be much better You may try it yourself, it should be very fast. Virtual (monitoring) table is bad here by the following reasons: - it could be very big, if Next-OIT is big - monitoring tables is not indexed - JOIN with such table will be not efficient - it will be populated for every monitoring snapshot even if no query requires it - it will be stable until transaction end - this is not what you need, i believe And we can add to the WHERE clause „AND RCN.TR_ID>=last_retrived_OAT” Hmm... not sure i got this idea Sorry wrong alias AND N.TR_ID>= last_retrived_OAT This is only for using index scan and read only portion of table instead of natural scan throught whole table. I should think on it more With only SNAPSHOT_CN we have same problem as with OAT. Please, explain It may not be necessary if the answer to the first question about what SNAPSHOT_CN is like is that I misunderstood its meaning. But when i read my above email i think that, first will be good to see sample about value of GLOBAL_CN (GCN) and SNAPSHOT_CN (SCN) and its real maining e.g. (maybe you can explain this shortly without answer to values of GCN, SCN here) I assume that all RC transactions below is actually RCRC transactions. SCN values below related to the corresponding transaction\statement. 1. dabase restored 2. First connection established (GCN=?, SCN=?) GCN = 1, SCN = NULL (there is no current transaction\statement) 3. Transaction 1 RC start 4. (GCN=?, SCN=?) GCN = 1, SCN = NULL (there is no current statement) 5. Transaction 2 RC start 6. (GCN=?, SCN=?) GCN = 1, SCN = NULL 7. Transaction 3 Snapshot start 8. (GCN=?, SCN=?) GCN = 1, SCN = 1 9. Transaction 1 select 10. (GCN=?, SCN=?) GCN = 1, SCN = 1 11.Transaction 2 select 12. (GCN=?, SCN=?) GCN = 1, SCN = 1 13. Transaction 3 select 14. (GCN=?, SCN=?) GCN = 1, SCN = 1 15. Transaction 1
[Firebird-devel] [FB-Tracker] Created: (CORE-5924) Automatic name of the field for RDB$GET_CONTEXT is not generated in the union
Automatic name of the field for RDB$GET_CONTEXT is not generated in the union
-
Key: CORE-5924
URL: http://tracker.firebirdsql.org/browse/CORE-5924
Project: Firebird Core
Issue Type: Bug
Affects Versions: 3.0.3, 4.0 Beta 1, 3.0.4
Reporter: Karol Bieniaszewski
SELECT RDB$GET_CONTEXT('SYSTEM', 'CURRENT_USER'), RDB$GET_CONTEXT('SYSTEM',
'CLIENT_ADDRESS'), R.RDB$CHARACTER_SET_NAME FROM RDB$DATABASE R
UNION
SELECT RDB$GET_CONTEXT('SYSTEM', 'CURRENT_USER'), RDB$GET_CONTEXT('SYSTEM',
'CLIENT_ADDRESS'), R.RDB$CHARACTER_SET_NAME FROM RDB$DATABASE R
--
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] ODP: CORE-5921
25.09.2018 19:02, Karol Bieniaszewski wrote:
What is then SNAPSHOT_CN?
This is the commit number of currently used snapshot, if present.
Non-RC transactions create snapshot at own start and SNAPSHOT_CN is the CN of
that snapshot.
RCRC transactions create snapshot when user query execution starts.
Old style RC transactions doesn't create snapshots.
> Is this last snapshot commited before my transaction start?
For non-RC transactions - yes.
Consider sample – what i try to accomplish (get deltas)
...
1. Start application
2. Start readonly transaction read commited transaction
3. Retrive TransactinStartCN and remember it as last_retrived_data_CN
RC transaction doesn't create snapshot for itself.
SELECT
*
FROM
NAMES N
INNER JOIN RDB$CN RCN ON RCN.TN=N.TR_ID
WHERE
RCN.TR_CN>=last_retrived_data_CN
Hmm... probably you want here
SELECT * FROM NAMES
WHERE RDB$GET_TRANSACTION_CN(RDB$RECORD_VERSION) >= :lastCN
4. Repeat point 3 in some interval to get deltas
If you want records inserted\update since last query, you need something like
a) declare variable i application with last CN and initialize it by 0:
int64 lastCN = 0;
b) run query which returns resultset AND currently used CN as one of the
resultset
column and put it into lastCN variable above:
SELECT NAMES.*, RDB$GET_CONTEXT('SYSTEM', 'SNAPSHOT_CN') as Current_CN
FROM NAMES
WHERE RDB$GET_TRANSACTION_CN(RDB$RECORD_VERSION) > :lastCN;
Note, you must query 'SNAPSHOT_CN' context variable in the same request if you
use RCRC transaction, or you may query it separately if you use SNAPSHOT
transaction.
In the latter case you should run query (b) in new SNAPSHOT transaction every
time.
TR_ID field is not needed as we can instead RCN.TN=N.TR_ID use
RCN.TN=N.RDB$RECORD_VERSION.
Yes, it is not needed. Probably for indexing purposes, if expression index on
RDB$RECORD_VERSION will not work (i didn't tried).
But this is for optimization only. We can add index there.
Expression index, correct ?
And we can add to the WHERE clause „AND RCN.TR_ID>=last_retrived_OAT”
Hmm... not sure i got this idea
This can add suport for real deltas.
With only OAT this is not possible as OAT is not so progressive. And in the worst case we can have same value throught whole day
(when some long running transaction exists).
I not speak about OAT (which relation to the delta i do not understand),
i'd say that we could have empty delta if there was no committed insert\update
operations since the last query.
Then asking for delta will got same resultset as previous delta which is not so
usefull.
If we will update our variable lastCN at (a) - we will get empty resultset,
AFAIU
With only SNAPSHOT_CN we have same problem as with OAT.
Please, explain
Regards,
Vlad
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] ODP: CORE-5921
What is then SNAPSHOT_CN? Is this last snapshot commited before my transaction start? Consider sample – what i try to accomplish (get deltas) CREATE TABLE NAMES ( ID integer NOT NULL, NAME varchar(100), TR_ID bigint, CONSTRAINT INTEG_2 PRIMARY KEY (ID) ); CREATE TABLE NAMES__DEL ( ID integer NOT NULL, CONSTRAINT INTEG_4 PRIMARY KEY (ID) ); SET TERM ^ ; CREATE TRIGGER TRIGGAD_NAMES FOR NAMES ACTIVE AFTER delete POSITION 0 AS BEGIN INSERT INTO NAMES__DEL(ID) VALUES(OLD.ID); END^ SET TERM ; ^ SET TERM ^ ; CREATE TRIGGER TRIGGAIU_NAMES FOR NAMES ACTIVE BEFORE insert OR update POSITION 0 AS BEGIN NEW.TR_ID = RDB$RECORD_VERSION; END^ SET TERM ; ^ 1. Start application 2. Start readonly transaction read commited transaction 3. Retrive TransactinStartCN and remember it as last_retrived_data_CN SELECT * FROM NAMES N INNER JOIN RDB$CN RCN ON RCN.TN=N.TR_ID WHERE RCN.TR_CN>=last_retrived_data_CN 4. Repeat point 3 in some interval to get deltas TR_ID field is not needed as we can instead RCN.TN=N.TR_ID use RCN.TN=N.RDB$RECORD_VERSION. But this is for optimization only. We can add index there. And we can add to the WHERE clause „AND RCN.TR_ID>=last_retrived_OAT” This can add suport for real deltas. With only OAT this is not possible as OAT is not so progressive. And in the worst case we can have same value throught whole day (when some long running transaction exists). Then asking for delta will got same resultset as previous delta which is not so usefull. With only SNAPSHOT_CN we have same problem as with OAT. Regards, Karol Bieniaszewski Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] CORE-5921
25.09.2018 17:25, liviuslivius wrote: Ok, i supposed that this go further. I need global CN from transaction start POV. For snapshot\concurrency transaction you could obtain it using SNAPSHOT_CN context variable. For read-comitted transaction it doesn't exists. I do not know if i can retrive it in On Transaction Start Trigger? Yes. And later too. Is that trigger serialized? No If i start transaction no other transaction can be commited until this trigger is finished? Of coure there is no such limitations. You know myTrStartCN:= GLOBAL_CN If not then TransactinStartCN will be also needed. As said above, it is available (and have sence) for non-RC transactions via SNAPSHOT_CN Also some virtual table with pair TN and CN should be available. Query RDB$GET_TRANSACTION_CN function in a loop. Probably, you need transaction IDs from OIT to Next. This will be good start point for some useful things. Hope, it helps Regards, Vlad Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] CORE-5921
Ok, i supposed that this go further. I need global CN from transaction start POV. I do not know if i can retrive it in On Transaction Start Trigger? Is that trigger serialized? If i start transaction no other transaction can be commited until this trigger is finished? You know myTrStartCN:= GLOBAL_CNIf not then TransactinStartCN will be also needed. Also some virtual table with pair TN and CN should be available. This will be good start point for some useful things. Regards,Karol Bieniaszewski nullFirebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] CORE-5921
24.09.2018 10:19, liviuslivius wrote: Hi, can you point me about usage cases about http://tracker.firebirdsql.org/browse/CORE-5921? The main goal is to provide ability to investigate new engine characteristics and behaviour for end users, testers, etc (i.e. not only for the core developers). Of course, anyone may use it for another purposes. Feel free to share your expirience ;) Regards, Vlad Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
