Re: [Firebird-devel] Improve release filenames
On Wed, 24 Aug 2022 16:04:20 +0200 Mark Rotteveel wrote: > On 24-08-2022 15:36, Dimitry Sibiryakov wrote: > > Mark Rotteveel wrote 24.08.2022 15:32: > >> If the term is confusing or ambiguous, it already is so in its current > >> form. > > > > Yes, it is. That's why I would suggest to change that. > > The Windows pdb packages are complete builds though. So maybe those > should be "debug", while the Linux builds should be "debug-symbols" or > something like that. The windows pdb packages contain complete builds partly because of the requirement that anything installable must be uninstallable. Just dropping a bunch of pdb's into the install dir will soone or later leave a mess behind it. More importantly, it is essential that the symbols exactly match the binaries, otherwise the debugger will complain and the whole exercise will be largely useless. Shipping a complete kit guarantees that everything will match up and can be uninstalled easily. But I agree with Dimitry - we should take care to distinguish kits containing debug symbols from actual 'Debug' builds. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Cleaning up Visual Studio detection during build and packaging.
We are currently doing this sort if thing in several batch files: if defined VS170COMNTOOLS () else if defined VS160COMNTOOLS () else if defined VS150COMNTOOLS () else which is very messy and hard to maintain. I've been working on fixing this and propose that we do this in settenvar.bat: if not defined VSnnnCOMNTOOLS if defined VS170COMNTOOLS set VSnnnCOMNTOOLS = VS170COMNTOOLS else if defined VS160COMNTOOLS set VSnnnCOMNTOOLS = VS160COMNTOOLS else if defined VS150COMNTOOLS set VSnnnCOMNTOOLS = VS150COMNTOOLS We then use VSnnnCOMNTOOLS to call the correct vcvarsall.bat. That then gives us almost all the environment variables we need for use during the build and then the subsequent packaging. With this clean up I've also fixed a few clumsy hacks in the code that tries to handle the disconnect between library names and numbers, msvc version numbers and Visual Studio version numbers. If a specific Visual Studio version is required then VSnnnCOMNTOOLS can be set in the environment prior to running the build. Overall the build code and the packaging code is a lot cleaner and is no less dependant upon a specific version of Visual Studio. Having a more flexible way to work with any available version of Visual Studio is important, I think. Microsoft has a fairly aggressive roadmap for VS releases and Github are deprecating older VS build environments quite quickly. Anyway, I'm ready to commit this directly to HEAD as long as there are no objections. Or I can create a work branch for review. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Status of 3.0.10
On Wed, 13 Apr 2022 18:35:29 +0300 Dmitry Yemanov wrote: > 13.04.2022 17:11, Pavel Cisar wrote: > > > > because 3.0.9 has significant regression (#7137 - we've got multiple > > > reports from large affected and unhappy users), I'd like ask what are > > > the prospect to release v3.0.10 soon. > > > > BTW, it would also address contracted collation performance issues that > > > we hoped would be addressed by 3.0.9, but as 3.0.9 release was rushed > > > ahead of schedule, this was deferred to 3.0.10. > > Let's make the release this month. I will start preparing the release notes. > > Ah! This means we need a solution to #7158 I haven't had time to fully investigate this. When I looked at the problem a few weeks ago I could reproduce the problem with the installer. But I've had problems reproducing it manually. For now, all I can suggest is that we remove the option to set legacy auth support in the Fb3 installer. This option has already been removed in Fb 4.0. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] set_build_target dot bat in HEAD
On Wed, 22 Dec 2021 13:14:43 -0300 Adriano dos Santos Fernandes wrote: > On 22/12/2021 10:12, Paul Reeves wrote: > > > > Is there any reason why set_build_target only tests for VS150COMNTOOLS ? > > > > Looks like no. > I've been looking into this more closely and it is a little more complex than I thought. I think our ultimate aim is to be able to choose a Visual Studio build environment and everything should 'just work', right through to final packaging. But things have got slightly muddled over the years, as different elements of the build and packaging process have been updated separately. Working out where to find the runtime libraries is the main problem, with a lot of duplication of code. I want to centralise this into a single place - setenvvars.bat. I shall commit some changes soon, but I also want to be 100% sure that I'm not breaking anything, especially with the holidays coming up. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] set_build_target dot bat in HEAD
On Wed, 22 Dec 2021 15:32:41 +0100 Dimitry Sibiryakov wrote: > Paul Reeves wrote 22.12.2021 14:12: > > Is there any reason why set_build_target only tests for VS150COMNTOOLS ? > > > > I'd like to add tests for VS160COMNTOOLS and VS170COMNTOOLS, unless there > > are any objections. > >Better question if this check is right because existence of some > redistributables has no relation with compiler that will be used to build > binaries and in the worst case can lead to wrong redistributables to be > included into package. > This is perhaps the main reason why I want to fix this. As it happens that piece of code should not even be in set_build_target. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] set_build_target dot bat in HEAD
Is there any reason why set_build_target only tests for VS150COMNTOOLS ? I'd like to add tests for VS160COMNTOOLS and VS170COMNTOOLS, unless there are any objections. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Build environments with Docker
On Tue, 7 Dec 2021 07:29:00 -0300 Adriano dos Santos Fernandes wrote: > It's prepared to generate Inno Setup installer kit, but it seems > failing for master, so currently only .zip kit is generated. This affects regular builds too, not just the docker image. The docker image needs the MSM module, as well as WiX. But there are also some changes required to the WiX projects as well as BuildExecutableInstall.bat and the innosetup script. I'm working on the fixes now. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Windows installer and ICU files
On Mon, 16 Aug 2021 17:34:09 +0300 Alex Peshkoff via Firebird-devel wrote: > > One detail - this should not be called "minimum client install". > This should be called "default install", Or maybe just call it 'client install', or 'client libraries install' ? > and _minimum_ one should behave almost like now - but tzdata is also not > needed. But this also poses the question - do we even want to support wht is currently the minimum client install in the installer. Who could actually use such a minimal client with Firebird 4.0 and later ? It might just be better to document what the absolute minimum is rather than encourage it. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Duplicated boost in Windows v4 RC1 kits
On Fri, 21 May 2021 11:12:27 -0300 Adriano dos Santos Fernandes wrote: > Hi! > > In v4 RC1 zip kits for Windows, there is duplicated boost directory. > > One in include/firebird/impl/boost (correct) and another in > include/firebird/boost (incorrect). > I think I've located the cause of the problem. I'll commit the fix once I'm sure. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Usage of 32b version of Firebird
On Tue, 2 Feb 2021 13:31:10 +0300 Alex Peshkoff via Firebird-devel wrote: > On 2/2/21 12:16 PM, Paul Reeves wrote: > > I doubt that our user base for 32-bit ARM is really very significant but > > 32-bit ARM chips probably have a good future ahead of them. > > Not sure. I visited eShop - only 46 cheap-most phones of 616 have 32-bit > CPUs. And they use chips developed in 2014. All the rest are at least > Cortex-A53. Actually, I wasn't thinking about phones. I was thinking more on the lines of the early Raspberries. And there are many more similar products such as Arduino. These 32-bit processor designs can have h/w costs that are almost in pennies, not dollars. That market is only going to get bigger. But as I said, we don't really have much of a user base there. At least at the moment. tl;dr - 32-bit x86 is more or less dead but 32-bit processors will be around for some time to come. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Usage of 32b version of Firebird
On Tue, 2 Feb 2021 11:32:42 +0300 Alex Peshkoff via Firebird-devel wrote: > On 2/1/21 10:24 PM, marius adrian popa wrote: > > My guess old cpus or installs > > > > Example got laptop with Windows 10 32 that is still supported by > > > Microsoft also have an old laptop with Ubuntu 32bit also another old > > > raspberry pi that is 32 bit only > > I doubt all that list is worth having _new_ versions 32 bit. > > > > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel > Presumably the original question implied x86 rather than 32-bit in general. I doubt that our user base for 32-bit ARM is really very significant but 32-bit ARM chips probably have a good future ahead of them. 32-bit x86 chips seem to largely have gone the way of 16-bit x86. I certainly ask myself the question about x86 quite frequently. I can see a reason for maintaining support in the code base but I find it hard to justify producing official x86 binaries for new versions of Firebird. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Builds with USE_VALGRIND fail
When I build HEAD with --enable-developer and -DUSE_VALGRIND I get
these errors:
alloc.cpp:2182:79: error: invalid conversion from ‘size_t (*)(size_t) {aka
long unsigned int (*)(long unsigned int)}’ to ‘unsigned int’ [-fpermissive]
common.h:772:51: error: invalid operands of types ‘size_t (*)(size_t) {aka
long unsigned int (*)(long unsigned int)}’ and ‘size_t {aka long unsigned
int}’ to binary ‘operator&’ #define ROUNDUP(n, b)(((n) + (b) - 1)
& ~((b) - 1))
alloc.cpp:2306:16: error: invalid operands of types ‘size_t {aka long
unsigned int}’ and ‘size_t (*)(size_t) {aka long unsigned int (*)(long
unsigned int)}’ to binary ‘operator-’ size = length - (VALGRIND_REDZONE +
GUARD_BYTES);
Similar errors appear when building B3_0_Release.
Should I log this as a bug?
Paul
--
Paul Reeves
http://www.ibphoenix.com
Supporting users of Firebird
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [firebird-admins] Re: [Firebird-admins] v3.0.7 release
On Wed, 21 Oct 2020 15:13:07 +0200 Mark Rotteveel wrote: > On 21-10-2020 12:50, Paul Reeves wrote: > > The new packages are now in the pre-release area. I've bumped the package > > number, so the previous URLs will probably no longer work. But I think > > this is necessary to help anyone who has already downloaded the packages > > that did not contain the employee db. > > The Firebird server reports itself as version 3.0.7.33374, not > 3.0.7.33374-1. Is that intentional? Yes - all the filenames of the windows packages have been in this format since, well, almost forever: majorver.minorver.rel.buildno-packageno majorver.minorver.rel.buildno is a part of the build process and this version numbering system is embedded in each binary. '-packageno' is only a part of the packaging process. It is largely cosmetic, and makes it easier and quicker to distinguish the two packages. And, iirc, the installer will see the package number too so it will know to upgrade if the earlier package had already been installed. > Based on a bug reported in 2018 for Jaybird[1] with parsing version numbers > for a macOS build (2.5.8.27089-1), I expected the build to report itself as > 3.0.7.33374-1. I guess the mac builds have different rules. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] OO API examples for Object Pascal
On Wed, 19 Aug 2020 05:47:59 +0300 Norbert Saint Georges wrote: > Paul Reeves a écrit : > > > > > Does anyone have any thoughts on this? > > > > > > Paul > > First of all, thanks for your code, it's nicer to read than c ++ :-) > > Just a question about the "read only" transaction in 03.select.pas on line > 224, you are not using the ptb initialized on line 217, normal? > No - that is an error. Thanks, I'll fix it. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] OO API examples for Object Pascal
On Tue, 18 Aug 2020 10:50:23 +0300 Simonov Denis via Firebird-devel wrote: > > Yes, it would be nice to have some wrappers to simplify programming. In fact, you have already done quite a bit of the work in your UDR examples. Especially the contents of the 'common' directory. I'd like to include those files because I have found they solve quite a few problems. And I would appreciate any suggestions you have. > It is desirable that the examples can be compiled in both FPC and Delpli. They are just .pas files and a makefile. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] OO API examples for Object Pascal
On Tue, 18 Aug 2020 10:38:19 +0100 Tony Whyman wrote: > Paul, > > I am not surprised that you wrote "it is more difficult than I thought". > When I set out to upgrade IBX for Lazarus to the new Firebird 3 OO API, I > thought that it would be a relatively straightforward task. :-) I know you have done some great work with IBX2 and I certainly don't have any desire to emulate it. Have you thought about putting this project onto github? It will get a lot more traction and other developers will find it easier to contribute patches. > The real question is who is the audience for the examples? Is it the > application programmer or is it the maintainers of packages such as IBPP, > Jaybird and the Firebird Pascal API? The answer to that question should > determine your objectives for the examples. I believe the audience is the application programmer in general rather than maintainers of packages. Simple examples that demonstrate the basics. As far as Object Pascal is concerned the old C api was too cumbersome to use in a quick application. The new api fits nicely with OP. For example, the two samples that I have converted so far - 02-update.pas and 03-select.pas - take up about the same number of lines of code as the C++ versions. But they do need a few helper units (but nothing cumbersome). To me that is impressive - It is now quite feasible to knock out a quick app that uses the new api in just a few lines of code. Nothing extra needs to be installed - just tell the compiler where to find Firebird.pas, libfbclient and the location of a few helper units. This would have been impossible with the old api. So I think one of the aims of these examples is to demonstrate the simplicity they bring to programming firebird applications in any language that supports the new api. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] OO API examples for Object Pascal
On Mon, 17 Aug 2020 14:07:25 -0300 Adriano dos Santos Fernandes wrote: > > I'd say its correct place would be a new project under the FirebirdSQL > organization. I agree and disagree. Yes - if we create what essentially would be a driver written in object pascal. That should certainly be in a separate project. But for now all I want to do is just create object pascal based copies of the c++ examples. They belong in the kits with the other examples. I'm certainly not interested in creating a driver - at least, not at this stage. My interest at the moment is in improving the examples that we ship in the kits. > There is no Java, .Net, etc in core, so should not be Pascal examples > there, specially, as you have figured out, the API is not easy to be > directly used by application developers. I'm not sure that this logic is sound. Personally I'd like to see java and .Net examples distributed. And any others languages that can connect to Firebird. Why not, for example, have 03.select.java that demonstrates the minimum required to do a select in java AND produces identical results to 03.select.cpp? Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] OO API examples for Object Pascal
On Mon, 17 Aug 2020 18:42:59 +0300 Vlad Khorsun wrote: > >VCL is overkill of course. We should avoid such dependencies in general > samples. Some thin wrappers\helper classes could be very good to have as > part of Pascal API. > Obviously the 'Visual' part of the VCL is overkill. :-) Actually I should have written RTL. But your comment made me think more clearly. Thanks. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] OO API examples for Object Pascal
On Mon, 17 Aug 2020 18:38:50 +0300 Alex Peshkoff via Firebird-devel wrote: > > First of all I'd like to see 2 new examples. Just to know what problems do > we discuss. I could either create a separate branch or I could just add them directly to a new sub-dir under examples in main. They have no outside dependancies so adding them to main cannot break anything. > PS. Vcl de-facto becomes part of pascal standard (if I'm not mistaken - I'm > rather far from that last time), so may be that integration is ok... In fact I should have written RTL - that is where all the base classes are declared. There is no need for the VCL at all. (Thank goodness.) Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] OO API examples for Object Pascal
I thought I would port the OO API examples to Object Pascal. After all, they are quite simple, so how hard could it be? In fact it is more difficult than I thought and I am not happy with the results. I've done two examples - update and select - and I would like to commit them but before doing so I'd like to discuss how we should proceed. In my opinion we should start a new sub-directory to contain all the object pascal code. This is because the examples will actually need several supporting files in a common directory. It would be best if the were kept clearly separate from other examples. But the main problem I have found is that if I try to copy the C++ style too closely all we end up with is very bad object pascal. It succeeds in demonstrating the new API but does not demonstrate good programming practice. However, if we want to demonstrate good programming practice we should probably integrate the examples into the VCL. And that might be a step too far. Does anyone have any thoughts on this? Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ../examples/include/example.h
It appears that I was looking at an older version of the api examples. How I did that, I do not know, but the error quickly became obvious once I started to prepare commiting the makefile for the deprecated api. Example.h does not need to be changed. On Thu, 13 Aug 2020 13:59:21 +0300 Alex Peshkoff via Firebird-devel wrote: > On 2020-08-12 19:32, Paul Reeves wrote: > > I'm working on re-creating the makefile for the api examples. I don't know > > how, but it seems to have got lost a long while ago. > > > > Almost everything still compiles in HEAD except for api16. > > > > This is because example.h has lost the declarations for 'args'. > > > > The history of example.h is interesting. There seemed to be a lot of > > disagreement as to what exactly it should contain. Sometimes 'args' was > > favoured. And other times not. Eventually 'args' lost. > > > > As the makefile for the api examples was also removed (don't know when) it > > seems nobody bothered to check whether the examples were buildable or not. > > > > So the question is - Should the 'args' defines be restored to example.h, > > or should they be declared in api16 which, I think, is the only place that > > requires them now. > > > > I would favour restoring them to example.h as there is commit history in > > that file. > > > > If you prefer example.h - I see no problems. > > > > > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel > -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] ../examples/include/example.h
I'm working on re-creating the makefile for the api examples. I don't know how, but it seems to have got lost a long while ago. Almost everything still compiles in HEAD except for api16. This is because example.h has lost the declarations for 'args'. The history of example.h is interesting. There seemed to be a lot of disagreement as to what exactly it should contain. Sometimes 'args' was favoured. And other times not. Eventually 'args' lost. As the makefile for the api examples was also removed (don't know when) it seems nobody bothered to check whether the examples were buildable or not. So the question is - Should the 'args' defines be restored to example.h, or should they be declared in api16 which, I think, is the only place that requires them now. I would favour restoring them to example.h as there is commit history in that file. (Yes, I know the isc api is deprecated but as long as we continue to ship the these examples in the kits they should build and there should be a makefile to build them.) Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Building 05.user_metadata.cpp
On Wed, 12 Aug 2020 15:48:28 +0300 Alex Peshkoff via Firebird-devel wrote: > ... > > Is this an error in the code or in my makefile? > > That's an old example, code needs fixing. Will fix in a day or two. > OK. No hurry for me. I just wanted to be sure that the makefile is not the problem. I'll commit the makefile as everything else builds without error. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Building 05.user_metadata.cpp
I'm working on a makefile to build the oo api examples. Everything is fine, except for 05.user_metadata.cpp Executing this: c++ -c -Wall -g3 -std=c++11 -fno-rtti -I/opt/firebird/include/ \ 05.user_metadata.cpp -o 05.user_metadata.o produces this error: 05.user_metadata.cpp: In function ‘int main()’: 05.user_metadata.cpp:212:14: error: invalid new-expression of abstract class type ‘MyMetadata’ meta = new MyMetadata; ^~ 05.user_metadata.cpp:46:7: note: because the following virtual functions are pure within ‘MyMetadata’: class MyMetadata : public IMessageMetadataImpl ^~ In file included from /opt/firebird/include/firebird/Interface.h:42:0, from ifaceExamples.h:39, from 05.user_metadata.cpp:33: /opt/firebird/include/firebird/IdlFbInterfaces.h:8875:20: note: unsigned int Firebird::IMessageMetadataImpl::getAlignment(StatusType*) [with Name = MyMetadata; StatusType = Base>Firebird::ThrowStatusWrapper; Base = Base>Firebird::IReferenceCountedImplFirebird::ThrowStatusWrapper, Base>Firebird::InheritFirebird::ThrowStatusWrapper, Base>Firebird::Inherit > > >] virtual unsigned Base>getAlignment(StatusType* status) = 0; ^~~~ /opt/firebird/include/firebird/IdlFbInterfaces.h:8876:20: note: unsigned int Firebird::IMessageMetadataImpl::getAlignedLength(StatusType*) [with Name = MyMetadata; StatusType = Base>Firebird::ThrowStatusWrapper; Base = Base>Firebird::IReferenceCountedImplFirebird::ThrowStatusWrapper, Base>Firebird::InheritFirebird::ThrowStatusWrapper, Base>Firebird::Inherit > > >] virtual unsigned Base>getAlignedLength(StatusType* status) = 0; ^~~~ Is this an error in the code or in my makefile? Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Page size 32K in FB4
On Tue, 26 May 2020 11:18:14 +0300 Alex Peshkoff via Firebird-devel wrote: > On 2020-05-26 11:11, Mark Rotteveel wrote: > > This looks like a bug in the statement parser. It seems to use signed > > > 16 bit int for this value, instead of an unsigned 16 bit int (or a > > > signed 32 bit int). This does make me wonder about the test coverage > > > for this feature. > > > > Could you create a bug in the tracker? > > > > Not reproduced on linux: > > # ./isql -z > ISQL Version: LI-T4.0.0.1976 Firebird 4.0 Beta 2 > Use CONNECT or CREATE DATABASE to specify a database > SQL> CREATE DATABASE 'test32.fdb' PAGE_SIZE 32768; > SQL> show db; > Database: test32.fdb > Owner: SYSDBA > PAGE_SIZE 32768 > > Try specifying a charset :-) Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ICU File Deployment Guidance
On Wed, 29 Apr 2020 13:16:11 +0100 Tony Whyman wrote: > I don't claim any expertise on linux time zone files. However, there is a > ubuntu package "tzdata" which claims to include all the timezone files. I > am currently using Linux Mint 19.3 (ubuntu 18.04) and the most recent > changelog entry for my version of the tzdata package is: > > tzdata (2019c-0ubuntu0.18.04) bionic; urgency=medium > FWIW, in SuSE the rpm is called 'timezone' and that too is up-to-date, at least in my version of 15.1. That is to say it has the 2019c updates. 2020a release only appeared this week, so it will probably arrive in a few days. IMO, we can probably assume linux distros that are being maintained will have the correct timezone files. And of course no-one would deploy to a linux server that wasn't running an actively maintained distribution. Can anyone confirm the situation with Windows? I find it hard to believe that Microsoft aren't on the ball with this. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] ICU File Deployment Guidance
On Wed, 29 Apr 2020 11:59:43 +0100 Tony Whyman wrote: > Hopefully, an installer package will eventually be made available to > automate the process. However, the above manual procedure is all that is > currently available. I'm wondering how people think we could automate this process. Thoughts that immediately come to mind are: - We have no control over the release cycle of tzdata. The update to https://github.com/FirebirdSQL/firebird/tree/master/extern/icu/tzdata seems to be manual at the moment. - Looking at the update history over at https://github.com/unicode-org/icu-data/tree/master/tzdata/icunew there can be up to 10 changes per year. - The changes will, in all probability, more than 99% of the time, have no relevance for over 99% of our users. But can one take the risk of ignoring them? - Even if we can provide timely, automated updates how will a server installation know to look for them? A task scheduler of some sort would need to check. We don't have one built in to Firebird so it would mean adding something platform specific. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Installing the ICU Files under Windows
On Tue, 28 Apr 2020 14:13:20 +0100 Tony Whyman wrote: > One reason that I could not check this is that I couldn't find any Windows > Installer source files in the source code distribution. Does Firebird use > Open Source WIX XML files for the installer or some proprietary tool to > create the .msi file? The installer uses InnoSetup. I'd recommend getting the firebird code fresh from GitHub, rather than a source tarball. Code is tagged anyway, so you can easily switch the checkout to a different tag if you want to travel back in time. In the meantime, the installer is being updated for Beta 2, and it is likely to change frequently over the next few days. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Introduction of EXTENDED TIME/TIMESTAMP WITH TIME ZONE?
On Tue, 10 Mar 2020 11:34:40 +0100 Dimitry Sibiryakov wrote: > 10.03.2020 09:48, Alex Peshkoff via Firebird-devel wrote: > > May be for old windows versions - yes, some problems. All the others > > upgrade ICU as a part > of regular OS upgrade. I.e. if one already has > > local ICU extended format is definitely > useless overhead. > >ICU appeared only in recent builds of Windows 10. Windows 7-8 and > servers don't have it. Some Linux distros package ICU in a very strange way > with names that Firebird don't know how to use. > > One of the perennial problems with building firebird on opensuse is the non-standard version numbering that opensuse use. Of course, the icu version required by firebird 3 is different to firebird 4 and they are both different from the icu deployed with the released version of opensuse. I've tried hacking the firebird code without much success and I've tried applying patches that have worked in the past, again without much success. Soemtimes they work. Sometimes not. I usually end up just digging around for community repos to find a version of icu that will build with firebird. But that doesn't solve the underlying problem. Another aspect, which is more personal, is that like most Anglophones I don't really need the character support provided by icu. And living in a country with a single time zone I don't need the time zone support either. For me icu spells Aaargh!!! :-) Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Interbase vs Firebird by Embarcadero
On Wed, 26 Feb 2020 16:48:29 +0100 Dimitry Sibiryakov wrote: > 26.02.2020 15:39, Paul Reeves wrote: > > Been there, looked at that :-) > > > > AFAICT it is for InterBase 2020 which is only available for Windows at the > > moment. The tests in the article were done with XE7. And my test rig uses > > linux. So I need a version of XE7 for linux. > > >It is available at https://cc.embarcadero.com/item/30771 but I have no > idea if you can get license for it now. > > That link is only for existing, registered, users. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Interbase vs Firebird by Embarcadero
On Wed, 26 Feb 2020 15:35:16 +0100 I wrote: > The idea of the failsafe comparison is valid but it depends on how they have > configured journalling. Under light load the cost of journalling will > have limited impact as it will almost certainly be cached. The journalling documentation is here. http://docwiki.embarcadero.com/InterBase/2020/en/Enabling_Journaling_and_Creating_Journal_Files It seems to contain two contradictory statements. On the one hand it says: > The journal file I/O is always synchronous and cannot be altered and in an earlier section on the same page we can read about the PAGE CACHE setting: > Determines the number of journal pages that are cached to memory. This > number must be large enough to provide buffers for worker threads to write > to when the cache writer is writing other buffers. It defaults to a hundred buffers. My reading of that is that there is only one cache writer, and journal writes are queued in the memory cache until they are finally written out to disc. The only different to Firebird's asynchronous writes that I can see is that journalling uses its own cache instead of the filesystem cache. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Interbase vs Firebird by Embarcadero
On Wed, 26 Feb 2020 14:23:32 +0100 Dimitry Sibiryakov wrote: > 26.02.2020 13:46, Paul Reeves wrote: > > If anyone can let me have a copy of InterBase XE7 I would be happy to run > > some proper comparisons on our test rig. > >Developers Edition is free to download from Embarcadero web site: > https://www.embarcadero.com/products/interbase/developer/free-download > > Been there, looked at that :-) AFAICT it is for InterBase 2020 which is only available for Windows at the moment. The tests in the article were done with XE7. And my test rig uses linux. So I need a version of XE7 for linux. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Interbase vs Firebird by Embarcadero
On Wed, 26 Feb 2020 16:28:38 +0300 Alex Peshkoff via Firebird-devel wrote: > On 2020-02-26 15:46, Paul Reeves wrote: > > AFAICT most of the content of that document is rubbish. They have > > certainly skewed our support costs heavily, using the most extreme > > examples. > > It's also unclear what point version of FB3 was used - 3.0.0 or something > newer like 3.0.4. I'm sure they give different scalability results. > > > The tpc-c performance figures look extremely suspect. Does anyone > > seriously do tpc-c testing with 2 warehouses? It doesn't make sense to me. > > > > Looking at the figures for the full table scan it looks as if they have > > created a 16 warehouse database. This will occupy around 1.5 GB of disc > > space and can easily be loaded in memory. This in itself has an impact on > > the quality of the test results. > > > > The InterBase tests were done with journaling and async writes compared to > > Firebird with synchronous writes. We don't know the journalling > > configuration. We also don't know how long the tests were run for. And > > neither do we know anything about the speed and latency of disc > > sub-system. If the run is short then journalling would have minimal > > overhead and InterBase writes would just be cached while Firebird would > > write straight to disk. So basically the comparison would be invalid. > > More realistic performance comparisons would be > >o with journalling off and sync vs sync > >o journalling off and async vs async > > Here I can't agree with you. They compare 2 recommended fail-safe > configurations - IBase with journalling (due to journalling there is no > need to use sync writes) and firebird with sync writes (we have no other > way to be fail-safe). The idea of the failsafe comparison is valid but it depends on how they have configured journalling. Under light load the cost of journalling will have limited impact as it will almost certainly be cached. So it is quite possible to create a test which gives the impression that Firebird is slow in comparison. Which is why I was suggesting other simple comparisons that are more like for like. > What will be very interesting re journalling - compare interbase with > journalling and async writes vs. interbase without journalling and sync > writes. This can give us an idea what effect does journalling give. Agreed - that is also a test that be interesting to carry out. Under a realistic load, of course. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Interbase vs Firebird by Embarcadero
AFAICT most of the content of that document is rubbish. They have certainly skewed our support costs heavily, using the most extreme examples. The tpc-c performance figures look extremely suspect. Does anyone seriously do tpc-c testing with 2 warehouses? It doesn't make sense to me. Looking at the figures for the full table scan it looks as if they have created a 16 warehouse database. This will occupy around 1.5 GB of disc space and can easily be loaded in memory. This in itself has an impact on the quality of the test results. The InterBase tests were done with journaling and async writes compared to Firebird with synchronous writes. We don't know the journalling configuration. We also don't know how long the tests were run for. And neither do we know anything about the speed and latency of disc sub-system. If the run is short then journalling would have minimal overhead and InterBase writes would just be cached while Firebird would write straight to disk. So basically the comparison would be invalid. More realistic performance comparisons would be o with journalling off and sync vs sync o journalling off and async vs async o with a very large database that cannot fit in memory/file cache with a realistic number of concurrent connections. This would effectively bottleneck at the filesystem level, thus removing the advantage of asynchronous file writes. Then we could see if their configuration outperforms firebird. Coming back to the data for the full table scans. How did they do that? It certainly wasn't with a simple sql statement in isql. However, I created a simple stored procedure that scanned the orders table in 0.261 seconds (10 warehouses, 300,000 rows, Firebird 3.0 SS.) The database was on a single, old-fashioned HDD. If anyone can let me have a copy of InterBase XE7 I would be happy to run some proper comparisons on our test rig. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] After_Installation.url
On Mon, 13 Jan 2020 12:15:56 +0100 Dimitry Sibiryakov wrote: >Hello, All. > >What's the point to have version number in URL if the site redirects > everything to the same static page? > My reasoning is that it is better to supply the version number. It doesn't cost much. And if, one day, the web server wants to use that value, the url will go to the correct page. There are quite a lot of differences between 2.5, 3.0 and 4.0. But unless the web-server has pages that make this distinction, this doesn't matter. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] GPRE and examples
On Thu, 9 Jan 2020 15:42:50 +0100 Dimitry Sibiryakov wrote: > 09.01.2020 13:53, Paul Reeves wrote: > > So the question should whether to include dynamic gpre examples in the > > packages or just remove them from the repo. As far as I know they have > > been deprecated for a long while and have not been shipped in the product > > since maybe even InterBase days. > >On the other hand they are mentioned in readme and CMakeLists.txt. > CMakeLists.txt is not the definitive package list. It is just for CMake, isn't it? And CMake is not used for either the 'official' windows or linux builds. Both are still done natively. Which readme are you referring to? Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] GPRE and examples
On Thu, 9 Jan 2020 13:14:22 +0100 Dimitry Sibiryakov wrote: >Hello, All. > >Currently distributed packages include GPRE but not examples for it. > Shouldn't it be either both or none? > To be more precise, the static examples are included the dynamic ones are not. So the question should whether to include dynamic gpre examples in the packages or just remove them from the repo. As far as I know they have been deprecated for a long while and have not been shipped in the product since maybe even InterBase days. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Inno Setup version for official distributive
On Mon, 6 Jan 2020 17:32:06 +0100 Dimitry Sibiryakov wrote: > 06.12.2019 20:08, Paul Reeves wrote: > > But I guess we should upgrade anyway. Perhaps a more pertinent question > > would be too ask whether we need to stick with v5. We haven't hacked > > the code. We just use InnoSetup from a standard install so there is no > > reason to stay with an older version unless v6 actually breaks the > > existing install script. > >I've found one case: in Inno 6 Bosnian language was excluded from the > main package. What will we do? Drop this language like many others or stay > with Inno 5? > > There is a place to download additional innosetup language packs, iirc. And it is possible that it will be added back in at a later date. And I would guess an old pack would work for most of the strings anyway. It is certainly not a reason to stay with InnoSetup v5. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Version of touch used for package building
On Thu, 2 Jan 2020 16:40:22 +0100 Dimitry Sibiryakov wrote: > 30.12.2019 17:45, Dimitry Sibiryakov wrote: > > BTW, currently this piece of code isn't called at all because of > > mistype in variable name. > >Do we want to use this trick at all? It was handy at DOS time when files > had no version resource inside, but nowadays it is rather obsolete, no...? I meant to reply earlier - I agree this is not needed nowadays. It was added right at the beginning of Firebird. Borland used to do it (I think), and I just copied it. It is useful from a visual perspective though as it is easy to spot files that have been edited or binaries installed from different packages. I'll take a look at the code and see if I can fix it. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6209) I've been waiting for Firebird-test Approval. Please advise.
You sent a mail to a mailing list using a mail address that was not recognised by the mailing list. The solution is to subscribe to that mailing list if you have not already done so. If you have already subscribed you must always use the mail address you subscribed with. On Mon, 16 Dec 2019 21:09:53 + (UTC) "Clyde Eisenbeis (JIRA)" wrote: > I've been waiting for Firebird-test Approval. Please advise. > - > > Key: CORE-6209 > URL: http://tracker.firebirdsql.org/browse/CORE-6209 > Project: Firebird Core > Issue Type: New Feature > Reporter: Clyde Eisenbeis > > > On 2 Dec 2019, I posted a request for a new feature. I received an email > from Adriano dos Santos Fernandes (JIRA) --- > asking for clarification. > > I responded with: > ` > It would be good if the embedded files were compiled into one dll. A code > writer would use this dll in creating a C# exe (that incorporates the use > of a stand-alone Firebird database). > > If a non-technical person wanted to use this database program, it would be > very easy to add the exe and the dll to their PC. The exe would create the > database and make it easy to use. > > A list of the embedded files can be found at --- > https://www.lawinegevaar.nl/firebird/jaybird_embedded_example.html --- > (which also applies to C#). ` Then I received an > email from --- "Your message > to Firebird-test awaits moderator approval". I did not know if Adriano > received the email from me, so I waited. > > Today I replied again to Adriano, and received another email from > --- "Your message to > Firebird-test awaits moderator approval". > > Please advise. > > > -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Inno Setup version for official distributive
On Fri, 6 Dec 2019 16:34:38 +0100 Dimitry Sibiryakov wrote: >Hello All. > >Do Inno Setup 6 have any significant advantage for Firebird over > currently used version 5? No is probably the short answer. The new features are mildy interesting. but nothing jumps out as a muct have. User resizable dialogs would be a nice addition (at least I think they are user resizable at install time), but the existing code already resizes dialogs where necessary. And I hate non resizable dialogs. Microsoft being one of the worst offenders. Do we need to support Admin and non-Admin installs? Who would use a non-Admin install? It is a long time since I used Windows in a locked down corporate environment. Is requiring admin privileges a problem? The support for side-by-side installs is interesting, but I wonder if it is a step too far. I can quickly see that getting too complicated too quickly, as the (un)installer tries to work out what has already been installed and what it can safely uninstall. Best to leave that to manual installation, imo. But I guess we should upgrade anyway. Perhaps a more pertinent question would be too ask whether we need to stick with v5. We haven't hacked the code. We just use InnoSetup from a standard install so there is no reason to stay with an older version unless v6 actually breaks the existing install script. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] FB4 asynchronous replication
On Mon, 7 Oct 2019 17:03:14 +0200 Dimitry Sibiryakov wrote: > 07.10.2019 17:00, Paul Reeves wrote: > > Both servers are using Beta1 > >Upgrade to snapshot. It had been fixed since then. > > Hmm - I thought of that, but couldn't see anything specific in the commit log. I'll try it. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] FB4 asynchronous replication
On Mon, 7 Oct 2019 16:30:00 +0300
Dmitry Yemanov wrote:
>
> verbose_logging is redundant here, currently it's used on the replica
> side only.
Thanks, I see now.
> > Replica:
> >
> > database = /srv/data/active/ods130/bmsql_smoketest.fdb
> > {
> >log_source_directory = /var/fb4-replication/bmsql_smoketest
> >verbose_logging = true
> > }
>
> log_source_directory should point to the same directory as
> log_archive_directory on the master side.
This does not appear in the documentation. As far as I can tell.
But anyway, I have now tried that.
Still no replication.
> > Both servers can see the log directory.
>
> They should see the log archive directory, this is what is shipped
> from primary to replica.
And I've double checked this - log_archive_directory on the source
specifies the same path as log_source_directory on the target. There is
no doubt that each server can see this directory. And the segment is
there:
ls -l /var/fb4-replication/archlog/bmsql_smoketest
total 4
-rw-rw 1 firebird firebird 699 Oct 7 14:31
bmsql_smoketest.fdb.chlog-1
What else am I missing?
Both servers are using Beta1 and synchronous replication works fine so
the firebird installation appears to be OK.
Paul
--
Paul Reeves
http://www.ibphoenix.com
Supporting users of Firebird
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] FB4 asynchronous replication
I'm trying to set up asynchronous replication and, afaict, I have
followed all the steps in the release notes correctly. But replication
does not happen. Here is the config:
Primary:
database = /srv/data/active/ods130/bmsql_smoketest.fdb
{
log_directory = /var/fb4-replication/bmsql_smoketest
log_archive_directory = /var/fb4-replication/archlog/bmsql_smoketest
log_archive_timeout = 10
verbose_logging = true
}
Replica:
database = /srv/data/active/ods130/bmsql_smoketest.fdb
{
log_source_directory = /var/fb4-replication/bmsql_smoketest
verbose_logging = true
}
The target db is set -replica read_only. (I also tried -read_write)
The log directory is set 777.
The segments appear in the log directory.
The segments are copied to the archive directory, but not removed.
Both servers can see the log directory.
Nothing is written to the target database.
Nothing is written to the either of the replication logs.
What am I missing?
(BTW, synchronous replication 'just works'.)
Paul
--
Paul Reeves
http://www.ibphoenix.com
Supporting users of Firebird
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Reopened: (CORE-3900) VC runtime installer can reboot system prior to installation finishing
[ http://tracker.firebirdsql.org/browse/CORE-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Reeves reopened CORE-3900: --- I'll take another look. > VC runtime installer can reboot system prior to installation finishing > -- > > Key: CORE-3900 > URL: http://tracker.firebirdsql.org/browse/CORE-3900 > Project: Firebird Core > Issue Type: Bug > Components: Installation > Environment: Windows 7 fresh installation during first boot process >Reporter: Brenden Walker >Assignee: Paul Reeves >Priority: Minor > > If the VC runtime installer needs to reboot to finish installation it will > cause the FB installer to reboot the system with no warning (due to /qn > passed to msiexec) before the FB installer finishes. This page > http://desktopengineer.com/windowsinstallererrorcodes notes that msiexec > returns exit code 3010 if a reboot is needed perhaps running always with > /norestart and setting internal reboot required flag would be preferable. > The only time we've seen this is with freshly imaged Win 7 machines during > the first boot process. -- 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] Build error on Windows (Visual Studio 2015)
On Thu, 12 Sep 2019 15:13:51 +0200 Mark Rotteveel wrote: > On the other hand, I don't really see the point of maintaining both a > VS2015 and a VS2017 build. I guess there are three practical reasons... Firebird has to be compilable across lots of different platforms so maintaining different versions of VS helps guarantee that. Exclusive reliance on a single compiler and toolchain can lead to portability problems down the line. Shops that do more than just firebird development like to build everything with the same toolchain. It is not always possible to use the latest and greatest due to ...reasons. And then there is the fact that for anyone who doesn't work with C/C++ on a daily basis setting up a working VS environment is not a trivial task. A casual 'Oh, I'll just check that in the code' can easily turn into a half a day or more just downloading and configuring a new version Visual Studio. So overall I think it is useful. But MS don't make it easy. VS Project files are incompatible from one version to another by design. That has always struck me as really stupid. Forward migration is possible, but not backwards to an earlier version. (As far as I recall.) Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] UDR vs PSQL
On Mon, 17 Jun 2019 11:35:11 +0200 Jiří Činčura wrote: > > Perhaps the real comparison should be between UDR and UDF. > > I don't see what that would tell me. Except for the number itself. > Something particular you're looking for? > The plan is to deprecate UDFs in Firebird 4 and replace them with UDRs. So for me the question is whether a UDR is efficient enough to do that. From what you are saying, a simple UDR has worse performance than a simple SP, so presumably it will be significantly worse than a UDF. I have never compared load and call times for UDFs and SPs, but I have always assumed that a UDF will load and execute more quickly than a SP. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] UDR vs PSQL
On Mon, 17 Jun 2019 12:12:39 +0300 Alex Peshkoff via Firebird-devel wrote: > On 17.06.2019 11:23, Jiří Činčura wrote: > > Hi, > > > > what performance could one accept between UDR and PSQL? I see that > > UDR is about 30%-40% slower on my machine (just plain execution - > > empty UDR vs empty PSQL). Does that align with team's measurements? > > I'm not saying it's bad or slow. I'm just looking for some > > confirmation on numbers. > > Jiri, I've never measured that myself but looking at code appears > your performance estimation is correct. > Jiri, Perhaps the real comparison should be between UDR and UDF. Can you test that? Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 4: Could not find acceptable ICU library
On Tue, 11 Jun 2019 11:10:54 -0300 Adriano dos Santos Fernandes wrote: > On 11/06/2019 11:08, Dimitry Sibiryakov wrote: > > 11.06.2019 15:41, liviuslivius wrote: > >> Can i ask what is the problem? When i retrive data by client lib it > >> try to convert it to local timezone or what? > > > > Copy isql + fbclient.dll somewhere, connect to any database, > > select current_timestamp from rdb$database - BOOM! > > > > > Copy isql + fbclient.dll somewhere, connect to any database, select > 1 / 0 from rdb$database - BOOM! > But there is a difference - there is no existing, working code in production that uses 1 / 0. But there will be code that uses current_timestamp. Not only that, working code will expect current_timestamp to retain the existing format. It seems to me that the implementation of CURRENT_TIME/STAMP is the wrong way round. It should support the old behaviour. Instead of introducing LOCALTIME/STAMP to return current time without the zone we should introduce new variables that return time zones for those that need them. That may not solve the problem in [subject] but it will ease the pain of migration for many of our users. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] UDF lib works on Linux but crash on Windows (Error writing data to connection)
On Tue, 7 May 2019 10:54:53 +0200 Massimo Fazzolari wrote: > Anybody could help me to figure out what's wrong with the > FPC 64bit compiler? Is there any compile/linker flag that I should > use? It might help to tell us which compiler and linker flags you are already using. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Max lock slots for Classic Server v2.5 x64?
On Tue, 19 Mar 2019 16:03:21 + "Leyne, Sean" wrote: > > > There is very little documentation available on the Classic lock > > > manager related settings, which is why I ask the question in this > > > forum. Interested in v2. 5 limitations, but details/differences > > > for other versions would be appreciated. > > > > I assume you mean hash table slots: > > > > const SLONG HASH_MAX_SLOTS = 65521; > > That was what I was looking for? > > Is there any reason why for x64 builds that number could not be > increased? > As I understand it, a high number of slots will reduce the queue lengths at the cost of checking a lot of empty slots. Like everything else, there is a sweet spot. In your case the queues are typically empty so you could reduce the number substantially and still see an improvement in performance. I did some tests a while back which showed that hash slots greater than around 8000 actually decreased performance. But that was with the tpc-c benchmark. The results were consistent across architectures, with 1009 being slightly behind 31991, which itself was behind 16001. But in all cases 8009 was the winner. I didn't go deeper - it may be that the real sweet spot is between, say, 6,000 and 12,000, but again, it may also be database/application specific. But I would start with 8009 and maybe go upward slowly, rather than jumping to around 64K. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Building Firebird 2.5 on Windows
On Tue, 19 Mar 2019 16:36:25 +0200 Vlad Khorsun wrote: > 19.03.2019 15:48, Paul Reeves wrote: > > On Tue, 19 Mar 2019 15:33:23 +0200 > > Vlad Khorsun wrote: > > >> > >> The best (and only guarantee) is to use "official" compiler. > >> For fb25 on Windows it is VC8 (VS2005). > > > Actually, it is MSVC10 :-) > >VC10 is used for fb3 > > > MSVC8 was for 2.1, if I recall correctly. > >VC8 for 2.1 and 2.5 > Yes, you are correct. VC8 just seems to be from such a long time ago. In fact it is from a long time ago - I just checked and the files are dated 23 September 2005. Apologies to Bastian too. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Building Firebird 2.5 on Windows
On Tue, 19 Mar 2019 15:33:23 +0200 Vlad Khorsun wrote: > >The best (and only guarantee) is to use "official" compiler. For > fb25 on Windows it is VC8 (VS2005). Actually, it is MSVC10 :-) MSVC8 was for 2.1, if I recall correctly. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] CORE-6011 legacy authentication in Windows installer
On Wed, 6 Mar 2019 14:33:49 +0100 Mark Rotteveel wrote: > > Srp is not a legacy authentication, it is just slightly less secure > than Srp256 I'm wondering then if I understand the difference between AuthServer and AuthClient. My understanding is that AuthServer specifies the plugins the server will use to authorize client attachments. AuthClient specifies the plugins the client will use to make the initial connect to the server. So if we have the current default of AuthServer = Srp256 then surely an FB3 client that uses Srp will be rejected? If my understanding is correct srp is a form of legacy authorization, even if it does not use the legacy_auth plugin. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] CORE-6011 legacy authentication in Windows installer
The installer in FB4 Beta 1 doesn't implement this option correctly, simply because srp256 is not included if the user checks the box. That is simple to fix. However the underlying problem is more complex. We now have two forms of legacy auth (without an underscore) - srp for Firebird 3 and legacy_auth for Firebird 2.?. To correctly enable legacy auth at install time the installer should really be modified to present two questions to the user, one for Firebird 3 auth and another for Firebird 2 auth. This seems to me to be too complex for a click through install. Keeping a single question opens up FB4 servers to all legacy auth. Changing the question so that FB4 considers legacy auth to only include Fb3 and not FB2 _may_ be confusing for those not paying attention (like almost everybody). And there is a good argument to not offer either option at install time because enabling legacy auth weakens security. If we choose best security I wonder how much we risk alienating users who are not 200% committed to firebird. Like it or not we have a massive user base that is tied to legacy versions of firebird and that is not going to change overnight. In addition many of those use zero security at the un/pw level so don't really care about security. We want to take our users with us. To do so means keeping migration as simple as possible. What is the opinion of others on this subject? Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6011) Enabling legacy authentication in Windows installer leads to less secur config than possible
On Sat, 23 Feb 2019 17:54:40 +0100 Dimitry Sibiryakov wrote: > 23.02.2019 17:51, Paul Reeves wrote: > > It is linked to the fact that rpm installs don't allow > > interaction at install time, so the security database is not > > initialised. > >IIRC, rpm install 2.5 used to initialize security database using > random password for sysdba. Was it changed in 3.0? > I only know the suse packages. The security db was left unitialised. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] [FB-Tracker] Created: (CORE-6011) Enabling legacy authentication in Windows installer leads to less secur config than possible
On Sat, 23 Feb 2019 16:28:46 +0100 Mark Rotteveel wrote: > > I think that a lot of grief could have been avoided if SRP > initialization would have been done as part of the default > initialization of the security3.fdb in the distribution instead of > leaving that to the users. > As far as linux and Firebird 3 is concerned that is definitely a problem. It is linked to the fact that rpm installs don't allow interaction at install time, so the security database is not initialised. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 4 beta 1 Windows installer says it is suitable for production use
On Sat, 23 Feb 2019 09:03:05 +0100 Mark Rotteveel wrote: > The Firebird 4 beta 1 installer says (information after install): > > """ > Firebird 4.0 has undergone extensive testing and is > intended for widespread production use. However, users > are recommended to follow standard practices before > deploying this release on a production server. > """ > > For the next beta we should probably tweak this ti says it is **NOT** > intended for widespread production use. That is definitely a bug. I'm not sure what happened but there are meant to be two boiler plate readme's - one for dev releases and one for prod releases. That one is surely not appropriate for a beta. I'll look into it. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Building Firebird 4 on Windows
On Fri, 15 Feb 2019 11:50:11 +0100 Dimitry Sibiryakov wrote: > 15.02.2019 9:17, Paul Reeves wrote: > > First you need to click on the 'Desktop Development with C++' > >You are talking about installing of Visual Studio. My question was > different: is Build Tools > (https://blogs.msdn.microsoft.com/vcblog/2016/11/16/introducing-the-visual-studio-build-tools/) > enough? > Looking at the link you provided, I don't see anything there that conflicts with what I said, excpet that I was coming from a different angle. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Building Firebird 4 on Windows
On Thu, 14 Feb 2019 16:06:15 +0100 Dimitry Sibiryakov wrote: >Is "Build Tools" enough for that or whole Visual Studio 2017 must > be installed? > First you need to click on the 'Desktop Development with C++' workload and while on that tab make sure that the WinXP option is checked (it is off by default). You then need to go to individual components and make sure that the VC++ option for v141 tools is checked as well as the WinXP option. I _think_ everything else is optional. You also need to set VS150COMNTOOLS manually. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] What type of UUID we use in Firebird ? i guess Version 1
On Fri, 8 Feb 2019 17:44:16 +0200 marius adrian popa wrote: > What type of UUID we use in Firebird ? > I guess Version 1 > > UUIDs in MySQL are really not random > https://news.ycombinator.com/item?id=19085189 But are they meant to be random? I thought the only guarantee was that they are unique. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Performance - 2.5 vs 3.0 vs 4.0
On Thu, 24 Jan 2019 10:49:14 +0300 Roman Simakov wrote: > чт, 24 янв. 2019 г. в 10:25, liviuslivius > : > > > > Hi. > > > > I have thinked about oltp comparision, and i think that comparing > > e.g. classic vs superserver on RAM disc is wrong. Why? Because read > > from "disc" is as fast as read from cache. > > This case eliminates disc problems and allow to highlight other ones. > In other words RAM simulates the very good system IO like a PCIe-SSD. > Except not all SSDs are the same. There is an interesting video from linus tech tips here which gives an insight as to why: https://www.youtube.com/watch?v=OffzVc7ZB-o Basically most newer SSDs use more layers which means real world performance is now worse than for SLC based SATA SSDs from a few years back. The video reviews an intel ssd, but I've done (firebird-based) tests with a Samsung 970 EVO NVMe M.2 which also has poorer performance under heavy load than an older SATA based SSD. It is easy to think that m.2 must be better than PCIe which must be better than SATA but the reality is that the internal design of the NAND is the most important. It is interesting also to note that the load test I mentioned above with a RAM disk based DB also behaved differently to both the RAID10 HDD test and the tests with different SSDs. Number of CPUs did not seem to be as important. So, to summarize, in my opinion a RAM disc does simulate a very good system IO. But this is NOT synonymous with the IO from a real disc subsystem. Basically a RAM disc will reduce IO to the absolute minimum available with today's technology. But it is probably not the most suitable location to host a firebird database so the performance results would be invalid. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Unknown tag value - missing in the list of possible
While debugging a an api call I got the error message in which obviously means I need to check the dpb in this case but I'm intrigued about this error message... What is it actually trying to say? - Is it just saying the same thing twice - because the tag value is invalid it is obviously missing from the list of possible tag values ? - Or is it that this tag value is not available among the possible tag values for this call ? - Or is it something so obvious that I'm just missing it completely ? - Or ? Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Meltdown and Spectre
On Tue, 9 Jan 2018 12:25:24 +0200 Sergey Mereutsa wrote > > Both vulnerabilities are LOCAL :) > Your server also has to be air-gapped from the internet and all its clients must also be air-gapped from the internet. If there is any connection to the outside world then all bets are off as one flaw can used to exploit another. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Meltdown and Spectre
On Tue, 9 Jan 2018 09:52:59 + Omacht András wrote > > Average running time on 4.9.0-4: 466 secs (7 mins 46 secs) > Average running time on 4.9.0-5: 635 secs (10 mins 35 secs) That is a massive hit. Has anyone had a chance to run tests on AMD kit? Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Build sources
On Fri, 13 Oct 2017 11:16:07 +0200 liviuslivius wrote > Or only possibility is build from command line and then run from the > ide to debug? I think the only way is to execute run_all.bat from the command line with the JUSTBUILD parameter just once. That will make sure that all the required components have been built in the correct order. Or you could do all that manually. The solutions are not set up to do it for you. Once you have done that you should be able to load the firebird solution and work 'as normal'. Until libtomcrypt has been ported to MSVC14 you will need MSVC12 or 13. And if you are working on HEAD you will likely find other small bits that are missing. Don't forget that HEAD is still in alpha. You may find working with the FB 3 branch easier to get started on. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-5629) gstat output does not include datetime of analysis
gstat output does not include datetime of analysis -- Key: CORE-5629 URL: http://tracker.firebirdsql.org/browse/CORE-5629 Project: Firebird Core Issue Type: Improvement Components: GSTAT Reporter: Paul Reeves Priority: Minor It would be nice to have a timestamp in a gstat report otherwise it is necessary to rely on the file creation date, which is not always correct. This could be the first line of gstat output, just before the Database "/path/to/my.fdb" line. Perhaps something like Gstat execution timeSep 30, 2017 12:00:00 I would guess that this might be easy enough to add to 2.5.8, 30.3 and 4.0 It might also be useful to add a timestamp at the end of the output as large databases can take quite a while to analyse. -- 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 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Understanding OLTP results
On Mon, 11 Sep 2017 15:06:05 +0200 Gabor Boros wrote > Hi All, > > I tried to compare Oracle Linux 7 Update 4 with kernel 4.1.12 and > 3.10.0. I wanted to know how much faster 4.1.12 than 3.10.0. But got > strange results. (Strange for me. :-) ) With 4.1.12 slower than > 3.10.0 and the FB3+3.10.0 is the slowest combination. Any idea why? Your figures show that FB3 and Kernel 4.1.12 was the slowest combination. Although it is interesting to see that FB 4 Alpha 1 is performing better than FB 3.0.3. Anyway, if I understand correctly the issue is with the kernels, not firebird. Have you tried other kernels from other distros ? ( 4.1 is getting old, now - the latest is 4.12, I think. ) Have you compared the compile params Oracle Linux uses ? Perhaps they have changed something. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Firebird.pas is missing
It looks as if a physical copy of Firebird.pas never got added to HEAD. So it is not included in the Alpha 1 windows kits. Unfortunately a few parts of the windows packaging code from B3_0_Release are also missing (my fault) so this didn't get picked up earlier. What is actually needed to generate firebird.pas? I looked at the code in Makefile.in and makeInstallImage.sh.in for the linux kits and it is not at all obvious what is needed to add this to the windows build process. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Problem in Windows zip kits
On Mon, 28 Aug 2017 14:47:43 +0300 Dmitry Yemanov wrote > 28.08.2017 14:42, Adriano dos Santos Fernandes wrote: > > > Paul, both things I've verified in 3.0 snapshot builds. > > > > I thought these zip kits was using the same process used to generate > > release zip kits. > > So the problem is in the snapshot kits? If so, I will check and fix > them. > The code to build the kits uses a devilishly complex sed script to strip all the license headers from the different include files and then concatenates the output to creawte ibase.h. The snapshots use code in make_all.bat, I think, to just concatenate the include files to ibase.h. It is quite possible that the files used to build the snapshot ibase.h are out of sync with the files used to build the one in the kits. It would probably be a good idea to concatenate ibase.h in make_all.bat and then I'll re-write the code in BuildExecutableInstall.bat to just strip comments from that file. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Problem in Windows zip kits
On Sat, 26 Aug 2017 19:04:28 -0300 Adriano dos Santos Fernandes wrote > Hi! > > I found two problems with include files: > > - ibase.h has #include "consts_pub.h" I can't find that line. I diffed the alpha1 ibase.h with the one from 3.0.2 and everything looks OK to me. There is new stuff added to Alpha1 but nothing seems to be missing. > > - include/firebird/impl is not included > In fact that is my fault. Several installer related commits to B3_0_Release never got forward ported to HEAD. I'm working on bringing all of them up-to-date now. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] fbclient - Event call back is called after isc_cancel_events
On Mon, 28 Aug 2017 11:01:16 +0200 Slavomir Skopalik wrote > > > > On 28.08.2017 04:15, Slavomir Skopalik wrote: > >> Should I create ticket for this? > >> > > > > No. Removing that call will break old code. > > You mean, old code will not crash so often. > How much time I have to wait to be sure that no more call back? > Or is there other technique how to solve it? > > > > >> From programing theory, no call back after successful cancel event > >> is allowed. > > > > To be precise - it happens during event cancellation. > > This is not true, call back happen in normal case few ms after > cancellation returns. > But on heavily loaded system, it can be few seconds. Maybe I'm missing something, but I seem to recall from the code that you posted that your listener is running on a timer in the main thread. The event listener should really be running in its own thread. Have you tried that? Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Problem in Windows zip kits
On Sat, 26 Aug 2017 19:04:28 -0300 Adriano dos Santos Fernandes wrote > Hi! > > I found two problems with include files: > > - ibase.h has #include "consts_pub.h" > > - include/firebird/impl is not included > Can you file that as a bug, and I'll fix it. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 3, stored procs and plans
On Fri, 25 Aug 2017 14:00:03 +0300 Dmitry Yemanov wrote > > > But whatever happened to the SP debugger? > > AFAIK, it was never started (although was discussed a bit). > And while on the subject of a debugger for SPs... There are commercial Stored Procedure debuggers available. And I've often wondered how they work. Presumably, each statement must be executed on the client such that the stored procedure's implementation is actually simulated. So the plans generated by a complex SP running in a third-party debugger will not necessarily correspond to the plans generated within the engine during actual execution. Which leads to a question... How/When are Stored Procedures prepared? A complex SP can have many different execution paths. Is each statement prepared as needed for each execution or are all statements prepared at once, during the initial prepare ? Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird 3, stored procs and plans
On Fri, 25 Aug 2017 12:28:17 +0300 Dmitry Yemanov wrote > > I agree it was handy in simple cases, but it had too many conceptual > problems. I accept that for all but the most simple cases the 'plan' was more or less useless. But just seeing PLAN (NATURAL) is extremely frustrating. Is there a simple hack I could do to build FB3.0 with the plan enabled for SPs? A better interim hack might be an option in firebird.conf but it would be a hack so I hesitate to propose it. But just knowing where to hack the code for a personal build might be useful for a few people. > I believe we need some other tool for this purpose, maybe > INSPECT or ANALYZE command for PSQL objects. Any better idea? It would certainly be a nice improvement to be able to study the internal execution of an SP in more detail. As for choice of COMMAND name - it doesn't seem as if there is a standard. Googling INSPECT produced hits for Oracle, but only in the sense that their documentation talks of inspecting an sql statement. ANALYZE seems to be the preferred term for MS-SQL but again, it didn't seem that the word is used as key word. Personally I think it would be better to extend PLAN and EXPLAIN with an option to dive into the details of a SP's execution rather than add a new command. But whatever happened to the SP debugger? If we had that, then I would be able to see the plan chosen for each statement in the SP, which would go a long way to helping me with my current problem. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Firebird 3, stored procs and plans
In FB 3.0 the plan output for stored procs is always PLAN (NATURAL) whereas with FB 2.5 the plan for each sql statement to be executed within the SP are returned. Not having the plan available in FB 3.0 makes it quite difficult to see what is actually happening in the SP. However, if we take any SP source, remove the 'create proc myproc' and insert 'execute block' and then prepare it with input param markers the plan (or plans) is/are actually returned. So obviously this information is available internally. How come it is supressed for SPs in FB 3.0? Is this a bug? Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Useful SQL Stored Procedures as part of standard firebird installation
On Sun, 13 Aug 2017 19:49:34 +0200 Slavomir Skopalik wrote > Hi Paul, > > I created https://github.com/skopaliks/Firebird-SQL-Lib > > but I have some stupid questions: > > 1. What kind of license will be best for this project? > > I chose LGPL3, is it ok? If the aim is that the stored procedures can one day be integrated into the Firebird distribution then the Initial Developer's PUBLIC LICENSE (IDPL) should be used. It is based on the original InterBase Public License (IPL) that was used for the release of InterBase source code by Borland. You can see the IDPL here: https://www.ibphoenix.com/about/firebird/idpl and the IPL here: https://www.ibphoenix.com/about/firebird/ipl > 2. What prefix do you prefer for this? > > I prefer LIB$, like LIB$CheckTriggerUniquePostion. > > Any other idea? That could work. Does anyone else have any thoughts on this? Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Useful SQL Stored Procedures as part of standard firebird installation
On Tue, 1 Aug 2017 11:49:42 +0200 Slavomir Skopalik wrote > Hi, > > will be possible to extend firebird installation by SQL stored > procedures that will solve common problems? > > It will be like UDF (let say in directory SQL), and every one can > include/use this SQL like fbudf. > It is a great idea. I'm sure I'm not the only one to have developed a few SPs over the years that might be useful. However, it needs someone to organise it, curate the contents and create QA tests to verify that the stored procedures work correctly with each new release. It is not too much work, but it does require commitment if the intention is that these procedures should ship with Firebird. Bit rot can set in very quickly if no-one is around to maintain code. Perhaps the first step would be to create a github project to allow people to contribute. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Result set from where afield = afield
While I was studying this sort of query: SELECT * FROM employee e WHERE e.EMP_NO = coalesce ( ?, e.EMP_NO) it became obvious that if the parameter is null it resolves to this sort of query: SELECT * FROM employee e WHERE e.EMP_NO = e.EMP_NO which produces the same result set as SELECT * FROM employee e Performance wise there is no difference that I can tell. However, is there a downside to using WHERE e.EMP_NO = e.EMP_NO to get a full result set ? ie, is this just an implementation artefact, or is this correct SQL that is always guaranteed to produce the same result as if the where clause had not been specified ? I've also seen, in stored procedures, this sort of construct... where (( e.EMP_NO = :AEMP_NO ) OR ( :AEMP_NO IS NULL)) which, if the input parameter AEMP_NO is NULL will also behave as if a full result set was requested. ie, the stored procedure will return a single record if AEMP_NO has a value and the entire table if it is null. The advantage of using that sort of construct is that only one SQL statement is required, rather than a more complex 'if then else' but is it safe from future implementation changes ? Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Optimisation of where afield = coalesce(value1, value2 )
On Mon, 10 Jul 2017 12:31:43 +0300 Dmitry Yemanov wrote > > > The other question I asked was... > > > > why can't I force the plan... > > > >PLAN (E INDEX (RDB$PRIMARY7)) > > Because it's invalid in this case. > I can understand that this plan might appear to be invalid from the perspective of the optimiser. But surely the whole point of adding the PLAN clause is because I think I know better than the optimiser what I want. So to return to the original query: where e.EMP_NO = COALESCE( ?, e.emp_no ) surely I ought to be able to add PLAN (E INDEX (RDB$PRIMARY7)) Then if the parameter resolves to a value at run-time the index will be used. Obviously if the parameter is null performance would be much worse than a natural scan because the engine must walk the index pages and then walk the data pages. But the customer is always right, surely :-) ( I also understand there is a downside to the customer always being right argument - one bad customer could screw everything up for all the others. But is that argument being used here or is it just because of the way the optimiser works? ) > > What are the rules for deciding when a PLAN statement will be > > rejected? > >>From one logical point of view if have this sort of query > > > >select * from mytable m where afield = whatever; > > > > and I add > > > >plan (m index(myindex )) > > > > the engine should accept that. Shouldn't it? > > It depends on "whatever". If it's literal or independent expression > or priorly evaluated field, index scan can be used. If it includes a > field from the same stream, it cannot. > Why not create a second stream in that case? that seems to be what happens when I create this query: SELECT * FROM employee WHERE EMP_NO = 2 OR EMP_NO is null this plan is chosen... PLAN (EMPLOYEE INDEX (RDB$PRIMARY7, RDB$PRIMARY7)) Because there are two streams the fetches and the indexed reads more or less double because of the OR clause. (Again, a subject for another day is why does the optimiser even bother with the second stream when EMP_NO can never be null ? ) Anyway, none of the above is any sort of criticism. I'm just trying to get a better understanding of the rules and maybe find out where things are broken that could be fixed easily (or hacked around). Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Optimisation of where afield = coalesce(value1, value2 )
On Fri, 7 Jul 2017 18:07:55 +0300 Dmitry Yemanov wrote > 07.07.2017 17:51, Paul Reeves wrote: > > > But that doesn't answer all my questions... > > > > Given > > > >where e.EMP_NO = COALESCE(?, e.emp_no ) > > > > and that there is an index on EMP_NO, why doesn't the optimiser > > default to the index. After all, it is logically more likely that a > > value will be passed in the where condition, rather than a NULL. > > To evaluate COALESCE, e.emp_no must be known. How it can be known > before we start reading the table (via index scan)? Chicken and egg > problem. > I understand that evaluating COALESCE(?, e.emp_no ) at prepare time may require a circular logic and is thus impractical but surely the more important piece of information is in the where e.emp_no = A unique index exists on this column so surely the optimiser should choose it instead of a natural scan ? The other question I asked was... why can't I force the plan... PLAN (E INDEX (RDB$PRIMARY7)) This error is raised... 'cannot be used in the specified plan' And a supplementary question (perhaps it merits a separate thread ) What are the rules for deciding when a PLAN statement will be rejected? >From one logical point of view if have this sort of query select * from mytable m where afield = whatever; and I add plan (m index(myindex )) the engine should accept that. Shouldn't it? Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Optimisation of where afield = coalesce(value1, value2 )
On Fri, 7 Jul 2017 11:27:26 -0300 Adriano dos Santos Fernandes wrote > > > It does not evaluate COALESCE at prepare time. > > It's just a expression which may or may not contain fields. > > If it doesn't contain fields, it will be the same as a simple "?" for > the plan calculation purposes. > > OK. That is not the answer I was hoping for :-) But that doesn't answer all my questions... Given where e.EMP_NO = COALESCE(?, e.emp_no ) and that there is an index on EMP_NO, why doesn't the optimiser default to the index. After all, it is logically more likely that a value will be passed in the where condition, rather than a NULL. In fact, considering the index is a primary key where e.EMP_NO = NULL would make no sense at all. Surely the logic ought to be if unique index on field then use index Also, even though a field is specified in the coalesce why can't I force the plan... PLAN (E INDEX (RDB$PRIMARY7)) This error is raised... 'cannot be used in the specified plan' Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Optimisation of where afield = coalesce(value1, value2 )
Given this simple SQL statement select e.emp_no, e.full_name from employee e where e.emp_no = coalesce(value1,value2 ) the plan varies depending on the following : 1. where e.EMP_NO = COALESCE(?, ? ) -- PLAN (E INDEX (RDB$PRIMARY7)) 2. where e.EMP_NO = COALESCE(2, ? ) -- PLAN (E INDEX (RDB$PRIMARY7)) 3. where e.EMP_NO = COALESCE(?, NULL ) -- PLAN (E INDEX (RDB$PRIMARY7)) 4. where e.EMP_NO = COALESCE(2, NULL ) -- PLAN (E INDEX (RDB$PRIMARY7)) 5. where e.EMP_NO = COALESCE(NULL, 2 ) -- PLAN (E INDEX (RDB$PRIMARY7)) 6. where e.EMP_NO = COALESCE(NULL, e.emp_no ) -- PLAN (E NATURAL) 7. where e.EMP_NO = COALESCE(2, e.emp_no ) -- PLAN (E NATURAL) 8. where e.EMP_NO = COALESCE(?, e.emp_no ) -- PLAN (E NATURAL) Examples 1 and 2 are correct. The index on EMP_NO exists, so use it. Example 3 is more interesting. The coalesce may evaluate to a value or to NULL. So even if NULL is evaluated there is no harm in choosing an index. Examples 4 and 5 will always evaluate to a value, so obviously an index should be used. Example 6 is interesting. As each row is selected emp_no will always evaluate to itself so the result set is the entire table. In this case a natural scan is correct. Example 7 certainly seems to have chosen the wrong plan. We already know the value of the expression when the statement is prepared. And examples 2, and 4 seem to prove that the optimiser is capable of evaluating the COALESCE during prepare and choosing an index. Example 8 could be considered correct if and only if ? evaluates to NULL. However, it seems to assume that the parameter will always be NULL and thus a natural scan should be used. However we have seen in examples 1 and 3 that it is equally capable of choosing an index when evaluating the coalesce even if the final evaluation may be null. And so here are the questions - is the plan produced in example 8 wrong or right ? - the above examples seem to lack coherence so how much is COALESCE evaluated during a prepare ? - should the optimiser assume that the first parameter will always resolve to a value - how does the optimiser consider COALESCE when this construct is used in a stored procedure? Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] udrcpp_example
On Wed, 5 Jul 2017 12:25:11 -0300 Adriano dos Santos Fernandes wrote > On 04/07/2017 11:33, Paul Reeves wrote: > > Building udrcpp_example fails under windows, and has done since at > > least the final release of Firebird 3.0. Unfortunately the build > > process doesn't detect the error. I shall commit a fix for that in a > > moment. > > > > Here is the error (repeated many times) : > > > > error C2896: 'bool > > Firebird::Udr::FactoryRegistration::run(Firebird::CheckStatusWrapper > > *,Firebird::IUdrPlugin *,void (__thiscall Firebird::IUdrPlugin::* > > )(Firebird::CheckStatusWrapper *,const char *,T > > *),Firebird::Udr::RegistrationNode *)' : cannot use function > > template 'void Firebird::IUdrPlugin::registerFunction(StatusType > > *,const char *,Firebird::IUdrFunctionFactory *)' as a function > > argument > > > > > Paul, please tests these patches (separately) and report the results > (including line numbers if has errors). > > They both compile under MSVC10. I tested with 32 and 64-bit. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] udrcpp_example
On Tue, 4 Jul 2017 18:39:40 +0300 Alex via Firebird-devel wrote > BTW - what version of VS fails? MSVC10 - the reference compiler for the Firebird 3 Windows builds. > What does newest version say about this place? I've only tried this so far on my FB 3 Build VM. Only MSVC10 is installed there. I'll try this on a development VM later. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] udrcpp_example
Building udrcpp_example fails under windows, and has done since at least the final release of Firebird 3.0. Unfortunately the build process doesn't detect the error. I shall commit a fix for that in a moment. Here is the error (repeated many times) : error C2896: 'bool Firebird::Udr::FactoryRegistration::run(Firebird::CheckStatusWrapper *,Firebird::IUdrPlugin *,void (__thiscall Firebird::IUdrPlugin::* )(Firebird::CheckStatusWrapper *,const char *,T *),Firebird::Udr::RegistrationNode *)' : cannot use function template 'void Firebird::IUdrPlugin::registerFunction(StatusType *,const char *,Firebird::IUdrFunctionFactory *)' as a function argument Shall I log this as a bug? Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Event Parameter buffer (EPB)
On Tue, 28 Mar 2017 12:51:34 +0300 Vlad Khorsun wrote > > PS The my own guess why such low limitation is documented - it is not > practical to pass large (up to 64KB) packet over the wire every time a > couple of events (of up to 252 registered) is fired. > >Time to process this packet also matters - why waste time looking > at > >200 event entries for changes in counts when just a few of them > >really > changed. > Thanks, Vlad, that makes sense. So basically, the limitation would seem to be artificial for recent versions of firebird, but still recommended from a performance perspective. (Which is the whole point of using events in the first place.) Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Event Parameter buffer (EPB)
Anyone ? On Mon, 27 Mar 2017 11:12:47 +0200 Paul Reeves wrote > The EPB is clearly documented as being limited to 15 events. I did a > fairly rough grep of the code and I failed to find where this > limitation is enforced. And I couldn't find anything in the release > notes to indicate that anything has changed since InterBase days. > > In practice this limitation is not a problem. It is also clearly > documented that if more than fifteen events need to be registered then > another EPB needs to be declared by the listener. > > But the question comes to mind - is this still a limitation or has > code refactoring or the move to 64-bit silently removed the limitation > without anyone noticing? Or have I missed something while grepping the > code? > > > > Paul > -- > Paul Reeves > http://www.ibphoenix.com > Supporting users of Firebird > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel > > Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Event Parameter buffer (EPB)
The EPB is clearly documented as being limited to 15 events. I did a fairly rough grep of the code and I failed to find where this limitation is enforced. And I couldn't find anything in the release notes to indicate that anything has changed since InterBase days. In practice this limitation is not a problem. It is also clearly documented that if more than fifteen events need to be registered then another EPB needs to be declared by the listener. But the question comes to mind - is this still a limitation or has code refactoring or the move to 64-bit silently removed the limitation without anyone noticing? Or have I missed something while grepping the code? Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] unix2dos
On Thu, 23 Mar 2017 16:35:32 +0100 Dimitry Sibiryakov wrote > 23.03.2017 16:09, Paul Reeves wrote: > > The reason we need it is because git seems to check (some) files out > > with LF eols and we need to deploy all text files with CR LF eols. > >It can be changed in .gitattributes. I'll look into that. As I mentioned, we needed a quick solution late in RC stage, and since then the issue has not been considered. At least, not by me. > > Yes, weirdly, gnuwin32 seems to implement non-standard parameters, > > at least for unix2dos, inasmuch as the --ascii switch is not > > available. OTOH, the --ascii switch on linux is the default and can > > be omitted. > >Utility which are bundled with git installer seems to be more > POSIX-compatible. It seems to be enough to add "c:\Program > files\Git\usr\bin" to PATH. Yes, that is a good idea. I'll do that. The original reason for choosing gnuwin32 was that there were no dependencies on external libraries - they were only linked to MS DLLs. And at the time DLL Hell was still a thing. But now that we are dependant upon git anyway we might as well use the resources that are provided with it. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] unix2dos
On Thu, 23 Mar 2017 16:05:57 +0100 Dimitry Sibiryakov wrote > 23.03.2017 15:58, Alex Peshkoff wrote: > > Occasionally BuildExecutableInstall.bat itself was wrongly > > committed to git - checked outon linux it has CR-LF lineend instead > > just LF. I.e. itself needs unix2dos ;) Luckily it does not actually > > matter. > >Actually, it does matter. Stupid Windows command line processor > works with "LF-only" files incorrectly. And because git's default > for .cmd files is "checkout as is", it must be kept in repository > with "CR-LF" EOL mark. > In this case the correct solution would be to commit .cmd files with CRLF eols. The packaging script only started needing to use unix2dos after the move to git because we cannot force the eol in text files that are used across different platforms. But we didn't discover this until late in the RC stage of v3.0.0, hence a rapid fix with unix2dos. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] unix2dos
On Thu, 23 Mar 2017 15:04:56 +0100 Dimitry Sibiryakov wrote >Hello, All. > >What version/build of subj supports '-D' switch Good question. If unix2dos is not found then an error will be thrown. It is not clearly documented but in the HELP screen there will be this: @echo o sed is required for packaging. Use the sed provided by @echo gnuwin32. The cygwin one is not guaranteed to work. Basically, if sed is available then unix2dos _ought_ to be available and the clue is in the 'provided by gnuwin32' If you google gnuwin32 you will arrive here http://gnuwin32.sourceforge.net/ that ought to be enough but I used https://sourceforge.net/projects/getgnuwin32/ which is supposed to simplify installation and maintenance of gnuwin32. I haven't upgraded the versions I use in years and the version in the help message doesn't correspond with the version in alt-Properties. To be honest it is a real hassle that we need to install so much just to have two small posix executables. Maybe things have changed with modern versions of windows and we could eliminate them now. But once the toolchain is installed it just works. > and what it is supposed to do in installation build script? Its purpose is clearly documented in the batch file just above where it is called, so I will not repeat it. The reason we need it is because git seems to check (some) files out with LF eols and we need to deploy all text files with CR LF eols. > If only to convert EOL marks, it is job for '-ascii' switch... Yes, weirdly, gnuwin32 seems to implement non-standard parameters, at least for unix2dos, inasmuch as the --ascii switch is not available. OTOH, the --ascii switch on linux is the default and can be omitted. And unix2dos on linux assumes that output will be in dos format - hence the name. Why the gnuwin32 version doesn't make that assumption is anyone's guess. So the -D (or --unix2dos in the long format ) is required. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] LibreOffice 5.3.0 is using firebird 3.0
On Thu, 9 Feb 2017 11:38:51 +0200 you wrote > LibreOffice Release notes > > https://wiki.documentfoundation.org/ReleaseNotes/5.3#Base > IIUC, every time you open/close a firebird database in LO it calls gbak to do a restore or a backup. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-5314) UDFs declared with large varchars take excessive time to execute
UDFs declared with large varchars take excessive time to execute Key: CORE-5314 URL: http://tracker.firebirdsql.org/browse/CORE-5314 Project: Firebird Core Issue Type: Bug Components: UDF Affects Versions: 2.5.6 Environment: Windows Reporter: Paul Reeves UDFs declared with large varchars take excessive time to execute An IBPhoenix client reported the following problem to us. A single udf, when declared with a 32k string length takes 20 times longer to execute than the same udf declared with a 16k string length. Likewise, declaring the UDF with a string length of 1K takes half the time again. Here is a quick summary of the times: f_strpos_huge - 60s f_strpos_middling - 3s f_strpos_1024 - 1.5s In all cases the same actual function was executed. The only difference was in the declaration. I have a test case which demonstrates the problem. -- 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 -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Centos7 and FB_CPU
On Wed, 29 Jun 2016 12:41:28 +0300 Alex Peshkoff wrote: > > In common.h there is > > #ifdef AMD64 > #define FB_CPU CpuAmd > > 2 master defines (-DLINUX -DAMD64) are placed into command line of > g++, therefore I hardly understand what happened. > If you provide full configure & make logs I hope I can explain a > reason. And certainly clean sources should build on CentOS 7. > If not we need have them fixed for 3.0.1. > > I tried with a clean checkout of B3_0_Release and everything built without problems. So it looks as if my previous source tree was mangled in some way. I had previously used to to do a build on another platform and just zipped it up and copied it across. So perhaps the problem, (apart from the user himself :-) ), is that 'make clean' does not make clean enough. I tried that a couple of times, as well as re-running autogen.sh and configure. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Centos7 and FB_CPU
On Wed, 29 Jun 2016 13:00:53 +0300 Alex Peshkoff wrote: > On 06/29/2016 12:42 PM, Paul Reeves wrote: > > On Wed, 29 Jun 2016 11:07:06 +0200 > > Paul Reeves wrote: > > > > symbol lookup > > error: > > /root/rpmbuild/BUILD/Firebird-3.0.0.32483-0/gen/Release/firebird/bin/isql: > > undefined symbol: fb_get_master_interface > > > > > > I'm wondering if there is an rpm dependency missing somewhere. I'm > > building on a box that did not have the full gnu toolchain > > installed, so I've been adding things bit by bit. > > Sooner of all linker at your box finds old fbclient library instead > new one, just built. > Yep, that fixed it. Thanks. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Centos7 and FB_CPU
On Wed, 29 Jun 2016 11:07:06 +0200 Paul Reeves wrote: > > I'll try building from the epel-7 source rpm and see if that works. > That seems to fix the FB_CPU problem And now I'm getting a new error : symbol lookup error: /root/rpmbuild/BUILD/Firebird-3.0.0.32483-0/gen/Release/firebird/bin/isql: undefined symbol: fb_get_master_interface I'm wondering if there is an rpm dependency missing somewhere. I'm building on a box that did not have the full gnu toolchain installed, so I've been adding things bit by bit. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Centos7 and FB_CPU
On Wed, 29 Jun 2016 10:36:54 +0200 Philippe Makowski wrote: > > I get this error: > > > > In file included from src/include/firebird.h:70:0, > > from src/gpre/movg.cpp:28: src/include/../common/common.h:555:2: > > error: #error Define FB_CPU for your platform > > > > > > Strange error you have, no idea why > > It is probably because I have tried to build the tagged Firebird 3.0.0 source. I notice in the fedora build logs that several patches have been applied. I'll try building from the epel-7 source rpm and see if that works. Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] Centos7 and FB_CPU
Firebird 3 doesn't seem to build on CentOS 7. I get this error: In file included from src/include/firebird.h:70:0, from src/gpre/movg.cpp:28: src/include/../common/common.h:555:2: error: #error Define FB_CPU for your platform I looked into configure and can see that $build gets defined as x86_64-unknown-linux-gnu so surely that ought to be enough information to define AMD64 but for some reason that does happen. Anyone got any ideas? Paul -- Paul Reeves http://www.ibphoenix.com Supporting users of Firebird -- Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-5284) Firebird fails to build with USE_VALGRIND
Firebird fails to build with USE_VALGRIND - Key: CORE-5284 URL: http://tracker.firebirdsql.org/browse/CORE-5284 Project: Firebird Core Issue Type: Bug Components: Build Issues / Porting Affects Versions: 3.0.0, 4.0 Initial Environment: Linux Reporter: Paul Reeves Priority: Minor The first build problem arrives with DELAYED_EXTENT_COUNT being used in anonymous namespace, before it has been defined globally. That was easy enough to work around. But then this error is thrown: alloc.cpp:1866:51: error: 'class Firebird::MemBlock' has no member named 'length' VALGRIND_MAKE_WRITABLE(object, block->length)); Looking at MemBlock there is certainly no length member, but MemBaseHunk does have one. -- 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 -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohomanageengine Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
