Change made to make Faster restores with gbak

There is a simple change which makes restores much faster, tested with Linux 2.5 embedded restore
Two databases, with two different tables filled with 2,000,000 records:
create table t1 (n1 integer);
create table t10 (n1 integer, n2 integer, n3 integer, …, n10 integer);

----------------------
Restore timings:
T1: 14.5s
T10: 20.5s

Improved gbak timings:
T1: 9.7s
T10: 14.7s
----------------------

The good news is there is still room to improve the restore speeds , here is Adriano’s tweet:

I do have a slight different method, to insert 100K records in less than 1s over the same localhost method.

Also confirmed by the ending of the article:

PS: There is other restore improvement capable of take down time from
around 8.5s to 0.5s over TCP, but it still requires some analisys.

pyfirebirdsql will become the next Firebird Python driver

Philippe Makowski wrote on the firebird-python list
The driver is hosted on github https://github.com/nakagami/pyfirebirdsql

First thanks Hajime Nakagami for your job

I really thinks that we need to put our effort on this driver so it became the Firebird Python driver instead of Kinterbasdb
here few points I saw :

– need a change in setup.py so install work
– transactions parameter we need the possibility to send custom transaction parameter buffers, for what I saw today transactions are (isc_tpb_write, isc_tpb_wait, isc_tpb_read_committed, isc_tpb_rec_version)
– need documentation
– can we extend it or create a new module to work with trace api ?

….

ps after a small change in setup.py I will certainly package it for
Mageia and Fedora

Firebird main website redesign : testers/proofreaders needed

We need all resources at the current stage of new web-site development.We have beta version now – www.firebirdtest.com, and it requires testing efforts.
The most important thing now is proofreading, so we need English native speakers first.

To report any problem, please create issues at tracker.firebirdsql.org in the Web site section http://tracker.firebirdsql.org/browse/WEB
(issues with wrong section will be not considered).
Please feel free to ask any questions.

PHP 5.3.6 released with changes for Windows users :VC++6 builds disabled

Officially VC++6 builds are dead (There are community builds but unsupported by core php developers)
Here is the announcement

Windows users: please mind that we do no longer provide builds created with Visual Studio C++ 6. It is impossible to maintain a high quality and safe build of PHP for Windows using this unmaintained compiler.

For Apache SAPIs (php5_apache2_2.dll), be sure that you use a Visual Studio C++ 9 version of Apache. We recommend the PHP builds as provided by ApacheLounge. For any other SAPI (CLI, FastCGI via mod_fcgi, FastCGI with IIS or other FastCGI capable server), everything works as before.Third party extension providers must rebuild their extensions to make them compatible and loadable with the Visual Studio C++9 builds that we no longer provide.

#AnyDAC Spring 2011 v 4.0.7 – #Delphi Components for Firebird, Interbase and more

DA-SOFT Technologies announces the availability of AnyDAC for Delphi Spring 2011 release v 4.0.7.1719 – high-speed, Universal Data Access Components for Firebird, Interbase, SQLite, MySQL, MS SQL Server, Oracle, PostgreSQL, MS Access, IBM DB2, Sybase SQL Anywhere, Informix, DbExpress, ODBC, that simplifies the task of building Embarcadero Delphi, C++Builder and Free Pascal Compiler database applications.

AnyDAC for Delphi can be immediately downloaded from the download page.

What is new in v4.0.7 and what is AnyDAC ?

Firebird internals : Asyncronous System Trap

What is Asyncronous System Trap ? : This is similar to Unixes signal’s or OS interrupts.
Technically this is callbacks from Lock Manager into the Engine called when
somebody acquires lock at level not compatible with current level. In this case
all processes who owns the lock receives notification and should take appropriate
action to release lock (immediately or deferred-ASAP).

The main trick with AST’s handlers is that AST is send asynchronously and
handler must take care to work correctly. Since v2.5 all ATS handlers runs in
separate thread. Before v2.5 it works using signals on Unixes and threads on
Windows.

PS the issue with old glibc and FB 2.5 is that since v2.5 we abandoned usage of old
System V semaphores (do you remember “semaphores are exhausted” error ? now
you can forget it completely) and start to use pthread mutexes. And old glibc have a
bugs in pthread mutex implementation.

1 23 24 25 26 27 57