Re: [Firebird-devel] test
On 17-2-2019 18:36, liviuslivius wrote: test message, because i have send two emails 16.02.2019 23:12 and 16.02.2019 23:27 but i still do see them on the group I have them in my mailbox now, it looks like they were stuck for almost a day within SourceForge: Received: from [127.0.0.1] (helo=sfs-ml-4.v29.lw.sourceforge.com) by sfs-ml-4.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1gvQuC-0007dD-7m; Sun, 17 Feb 2019 18:11:08 + Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-2.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gv8Cx-0008Ne-6p for firebird-devel@lists.sourceforge.net; Sat, 16 Feb 2019 22:13:15 + Probably some kind of outage. The host name change between these hops suggests that maybe mail queues had to be manually moved between servers (although it is also possible this is just a multi-homed host). Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] RDB$GET_TRANSACTION_CN works different in Super and Classic
18.02.2019 17:18, liviuslivius wrote: If you consider to remove it in CS only... Nobody going to remove it, don't worry ;) Regards, Vlad Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-6003) RDB$GET_TRANSACTION_CN works different in Super and Classic
RDB$GET_TRANSACTION_CN works different in Super and Classic --- Key: CORE-6003 URL: http://tracker.firebirdsql.org/browse/CORE-6003 Project: Firebird Core Issue Type: Improvement Components: Engine Affects Versions: 4.0 Beta 1 Reporter: Adriano dos Santos Fernandes Open two connections C1 and C2. C2: select current_transaction from rdb$database; -- let's call the result T2 C2: commit; C1: select rdb$get_transaction_cn(T2) from rdb$database; In Super C1 returns the commit number. In Classic it returns NULL. -- 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] RDB$GET_TRANSACTION_CN works different in Super and Classic
On 18/02/2019 08:47, Adriano dos Santos Fernandes wrote: > On 18/02/2019 08:37, Vlad Khorsun wrote: >> >> Seriously, if you (and others) consider it is important enough to >> try to refresh >> TIP cache in such cases - fill the ticket in tracker and i'll fix it. >> > If the change is going to appear only in Beta 2, then ok and I file a > ticket. Otherwise a ticket would not be necessary as the feature didn't > appeared in any alpha/beta release yet. http://tracker.firebirdsql.org/browse/CORE-6003 Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] RDB$GET_TRANSACTION_CN works different in Super and Classic
18.02.2019 15:01, Vlad Khorsun wrote: Second, Beta1 tag is already set so we need DY's opinion on this subject. The tag will be moved today, but please don't commit before that. This (even if fixed/changed) is not a showstopper. Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] RDB$GET_TRANSACTION_CN works different in Super and Classic
18.02.2019 13:01, Alex Peshkoff via Firebird-devel wrote: Just notice - if you do not use this function you will never have performance issue with it. It depends on the place where Vlad will put the TIP refresh to. -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] RDB$GET_TRANSACTION_CN works different in Super and Classic
18.02.2019 13:50, Dimitry Sibiryakov wrote: 18.02.2019 12:47, Adriano dos Santos Fernandes wrote: If the change is going to appear only in Beta 2, then ok and I file a ticket. Otherwise a ticket would not be necessary as the feature didn't appeared in any alpha/beta release yet. This change AFAIU will make Firebird even slower than it is now. It could make slower RDB$GET_TRANSACTION_CN only and only if its argument is larger than cached Next marker. I.e. it will not affect normal engine operations. Regards, Vlad Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] RDB$GET_TRANSACTION_CN works different in Super and Classic
On 2/18/19 2:57 PM, Dimitry Sibiryakov wrote: 18.02.2019 12:55, Alex Peshkoff via Firebird-devel wrote: On the other hand this should better be fixed afterwards - design where SS/CS provide different results is IMHO not good. Something like awful borland's SPB items that provide useful results only in SS. Well Borland can be excused here somehow - they were going to drop CS support. But ee are not goint to do it . May be the best fix would be to remove subj function? I see no practical usage for it in real applications. Do you? Not sure. Just notice - if you do not use this function you will never have performance issue with it. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] RDB$GET_TRANSACTION_CN works different in Super and Classic
18.02.2019 13:47, Adriano dos Santos Fernandes wrote: On 18/02/2019 08:37, Vlad Khorsun wrote: Seriously, if you (and others) consider it is important enough to try to refresh TIP cache in such cases - fill the ticket in tracker and i'll fix it. If the change is going to appear only in Beta 2, then ok and I file a ticket. Otherwise a ticket would not be necessary as the feature didn't appeared in any alpha/beta release yet. First, i need more opinions\agreement if this change is really required. Second, Beta1 tag is already set so we need DY's opinion on this subject. Regards, Vlad Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Setting time zone bind through DPB?
On 2/18/19 2:21 PM, Adriano dos Santos Fernandes wrote: On 16/02/2019 12:57, Mark Rotteveel wrote: BTW: similar arguments could be made for the SET DECFLOAT options, but I don't have a need there. The similar SET DECFLOAT wasn't it, so TIME ZONE didn't had too. That backward compatibility bindings were designed in order to make new features work somehow with old, having no idea about them, software. Such software hardly has a good way to place unknown to it items to DPB. New one should better use default bindings cause they provide best (from functionality POV) access to new features. So why overcomplicate server where it's not needed ? Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] RDB$GET_TRANSACTION_CN works different in Super and Classic
18.02.2019 12:55, Alex Peshkoff via Firebird-devel wrote: On the other hand this should better be fixed afterwards - design where SS/CS provide different results is IMHO not good. Something like awful borland's SPB items that provide useful results only in SS. Well Borland can be excused here somehow - they were going to drop CS support. But ee are not goint to do it . May be the best fix would be to remove subj function? I see no practical usage for it in real applications. Do you? -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] RDB$GET_TRANSACTION_CN works different in Super and Classic
On 2/18/19 2:47 PM, Adriano dos Santos Fernandes wrote: On 18/02/2019 08:37, Vlad Khorsun wrote: Seriously, if you (and others) consider it is important enough to try to refresh TIP cache in such cases - fill the ticket in tracker and i'll fix it. If the change is going to appear only in Beta 2, then ok and I file a ticket. Otherwise a ticket would not be necessary as the feature didn't appeared in any alpha/beta release yet. What I can say for sure is that this is not a reason to delay beta1. On the other hand this should better be fixed afterwards - design where SS/CS provide different results is IMHO not good. Something like awful borland's SPB items that provide useful results only in SS. Well Borland can be excused here somehow - they were going to drop CS support. But ee are not goint to do it . Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] RDB$GET_TRANSACTION_CN works different in Super and Classic
18.02.2019 12:47, Adriano dos Santos Fernandes wrote: If the change is going to appear only in Beta 2, then ok and I file a ticket. Otherwise a ticket would not be necessary as the feature didn't appeared in any alpha/beta release yet. This change AFAIU will make Firebird even slower than it is now. Are you sure that gain from this trade-off will be big enough? -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] RDB$GET_TRANSACTION_CN works different in Super and Classic
On 18/02/2019 08:37, Vlad Khorsun wrote: > > > Seriously, if you (and others) consider it is important enough to > try to refresh > TIP cache in such cases - fill the ticket in tracker and i'll fix it. > If the change is going to appear only in Beta 2, then ok and I file a ticket. Otherwise a ticket would not be necessary as the feature didn't appeared in any alpha/beta release yet. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] RDB$GET_TRANSACTION_CN works different in Super and Classic
18.02.2019 13:19, Adriano dos Santos Fernandes wrote: On 18/02/2019 05:50, Vlad Khorsun wrote: 18.02.2019 1:49, Adriano dos Santos Fernandes wrote: Open two connections C1 and C2. C2: select current_transaction from rdb$database; -- let's call the result T2 C2: commit; C1: select rdb$get_transaction_cn(T2) from rdb$database; In Super C1 returns the commit number. In Classic it returns NULL. Yes, this is because C1 see no new Next value and consider T2 as not existing. We could refresh TIP Cache in C1 but it looks as overkill in this case. That difference is not documented. README.builtin_functions.txt: --- Summary, numbers returned by RDB$GET_TRANSACTION_CN could have values below: ... NULL - given transaction number is NULL or greater than database Next Transaction --- Considering that (and not), was is the usefulness of RDB$GET_TRANSACTION_CN? It is completely useless, if you wish to say it ;) Seriously, if you (and others) consider it is important enough to try to refresh TIP cache in such cases - fill the ticket in tracker and i'll fix it. Regards, Vlad Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Setting time zone bind through DPB?
On 16/02/2019 12:57, Mark Rotteveel wrote: > > BTW: similar arguments could be made for the SET DECFLOAT options, but > I don't have a need there. > The similar SET DECFLOAT wasn't it, so TIME ZONE didn't had too. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] RDB$GET_TRANSACTION_CN works different in Super and Classic
On 18/02/2019 05:50, Vlad Khorsun wrote: > 18.02.2019 1:49, Adriano dos Santos Fernandes wrote: >> Open two connections C1 and C2. >> >> C2: select current_transaction from rdb$database; -- let's call the >> result T2 >> C2: commit; >> >> C1: select rdb$get_transaction_cn(T2) from rdb$database; >> >> In Super C1 returns the commit number. In Classic it returns NULL. > > Yes, this is because C1 see no new Next value and consider T2 as not > existing. > We could refresh TIP Cache in C1 but it looks as overkill in this case. > That difference is not documented. Considering that (and not), was is the usefulness of RDB$GET_TRANSACTION_CN? Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] PostgreSQL vs. fsync error
Yes. Always on all databases (~500 pieces on that server). (Filesystem is ext3.) András -Original Message- From: Alex Peshkoff via Firebird-devel Sent: Monday, February 18, 2019 10:45 AM To: firebird-devel@lists.sourceforge.net Cc: Alex Peshkoff Subject: Re: [Firebird-devel] PostgreSQL vs. fsync error On 2/17/19 10:35 AM, Omacht András wrote: > Dear Developers, > > https://wiki.postgresql.org/wiki/Fsync_Errors > > Firebird can be also involved in the problem? > > Perodically we have corrupted databases on linux (85% wrong page > type). And this cannot be reproduced for ages. Currently we are > running FB 2.5.8 on 4.1.12 kernel. > Is 'forced writes' set for you DB? 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] PostgreSQL vs. fsync error
On 2/17/19 10:35 AM, Omacht András wrote: Dear Developers, https://wiki.postgresql.org/wiki/Fsync_Errors Firebird can be also involved in the problem? Perodically we have corrupted databases on linux (85% wrong page type). And this cannot be reproduced for ages. Currently we are running FB 2.5.8 on 4.1.12 kernel. Is 'forced writes' set for you DB? Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Setting time zone bind through DPB?
On 2019-02-18 09:48, Alex Peshkoff via Firebird-devel wrote: Guys, you are mixing DPB & SPB. In crazy designed SPB one really can't use unknown for server items - server does not know how to skip unknown iten and proceed to next. DPB (both v1 & v2) has absolutely regular structure, one can safely add new items to it, old server can and will skip them. Ok, good to know (although I'll probably forget again). That does not mean that I like an idea of duplicating session tuning in DPB cause I do not see good reasons for it. Start session and issue startup sequence of SQL statements. I want to be able to call ALTER SESSION RESET in a way that it will reset the session as I configured it on attach (including bind config). The difference is that I assume things set through DPB to survive a ALTER SESSION RESET, while I would assume things set using SET xxx (eg SET TIME ZONE BIND) to be reset to the defaults (or DPB configured values). I may be wrong, but that would mean that ALTER SESSION RESET needs to be documented in a lot more detail than it is right now. Not being able to set an initial session config that will define the state after a session reset is I think a dangerous thing (or at least, something that may lead to confusion and vague bug reports). Mark Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Values for isc_dpb_session_time_zone
On 2019-02-18 01:24, Adriano dos Santos Fernandes wrote: On 17/02/2019 08:33, Mark Rotteveel wrote: It would be helpful if Firebird already had an explicit default value (as then I can just document that, and I don't need to have logic to treat a Jaybird specific value as 'don't set'). I don't think it should. Just don't add it to DPB. The difference is that if there were such a value, then I wouldn't need to built special provisions for this and I could just pass any value explicitly set by the user without second thought. On the other hand, I already need handling in place to set the JVM default if nothing has been set, so that could be handled there as well. Mark Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] RDB$GET_TRANSACTION_CN works different in Super and Classic
18.02.2019 1:49, Adriano dos Santos Fernandes wrote: Open two connections C1 and C2. C2: select current_transaction from rdb$database; -- let's call the result T2 C2: commit; C1: select rdb$get_transaction_cn(T2) from rdb$database; In Super C1 returns the commit number. In Classic it returns NULL. Yes, this is because C1 see no new Next value and consider T2 as not existing. We could refresh TIP Cache in C1 but it looks as overkill in this case. Regards, Vlad Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Setting time zone bind through DPB?
On 2/16/19 6:59 PM, Mark Rotteveel wrote: On 16-2-2019 16:04, Dimitry Sibiryakov wrote: 16.02.2019 15:57, Mark Rotteveel wrote: I was wondering if it was considered to also set these options through the DPB. Especially for time zone support, I'm currently considering not supporting this for Java 7 in Jaybird, and it would save some headaches if it were possible to control this through the DPB (eg explicit property or maybe using isc_dpb_config) instead of having to execute a statement after connect. One question: how are you going to decide whether these DPB options must be set (server is 4.0) or not (server 3.0-)? Thanks, I forgot about the minor annoyance of not being able to use unknown DPB items on lower versions. Guys, you are mixing DPB & SPB. In crazy designed SPB one really can't use unknown for server items - server does not know how to skip unknown iten and proceed to next. DPB (both v1 & v2) has absolutely regular structure, one can safely add new items to it, old server can and will skip them. That does not mean that I like an idea of duplicating session tuning in DPB cause I do not see good reasons for it. Start session and issue startup sequence of SQL statements. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
