Nabble - firebird-devel

Re: 2.5 RC2 change list

2009-12-15T13:06:53Z

> Is there a list somewhere of the 2.5 RC2 issues?

Do you need known issues or fixed (since RC1) issues ?

The latter you can pick up from the ChangeLog :

http://firebird.cvs.sourceforge.net/viewvc/firebird/firebird2/ChangeLog?r1=1.2008.2.1&r2=1.2008.2.21

Regards,
Vlad

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

2.5 RC2 change list

2009-12-15T12:39:29Z

Hey all -

Is there a list somewhere of the 2.5 RC2 issues? Can I pry it out of
the tracker? Our QA folks are enquiring...

TIA,
________________________________________________________
Richard Wesley Senior Software Developer Tableau
Software
Visit: http://www.trytableau.com/now.html

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: cross-version API/ABI stability of libib_util / posix

2009-12-15T07:34:55Z

-=| Alexander Peshkoff, Tue, Dec 15, 2009 at 12:48:47PM +0300 |=-

> On Monday 14 December 2009 23:42:42 Damyan Ivanov wrote:
> > Is it safe to load libib_util.so from 2.5 into 2.1 server? Into
> > 2.0 server? And libib_util from 2.1 into 2.0?
> > I hope the answer is yes. If not, I think the soname of libib_util
> > shall be changed to reflect backward-incompatibility. (Note that is
> > perfectly OK to say that 2.1 server needs libib_util of 2.1 or above).
> The answer is unfortunately 'no'. It's internals never changed
> before 2.5, but 2.5 is change-point.
>
> The UDF side of API has not changed. I.e. any UDF which successfully worked
> with ib_util in 2.1 and earlier version will continue correctly
> working with libib_util from 2.5.

I imagine the relief of all UDF authors and server administrators :)

> But internals of libib_util did change, it has additional entry
> point used by engine to initialize that library. To avoid use of old
> libib_util, engine itself preloads libib_util before first call to
> any UDF. And performs required initialization. In case when correct
> (having initialization entry point) library can not be found/loaded,
> UDF is not called, and user gets appropriate message, duplicated in
> firebird.log.
> ...

Thank you for the explaination. I guess what makes ib_util
a complicated library is that it has two APIs - one for UDF (that
remains unchanged in 2.5) and one for the server (which is new in
2.5).

> What about your problem. I think the correct solution is to keep
> pre-2.5 libibutil as is (in /opt/firebird/lib), placing new
> libib_util into /usr/lib. I do not suppose it's internals to be
> changed in the nearest 10 years :-)

Right. Famous last words :-p

> It's technically possible (and very easy) to make libib_util have
> legacy behavior if initialization was not done. Taking into an
> account, that currently when ib_util_malloc() is called in not
> initialized library it's anyway segfault for 99% of UDFs, I start to
> think that keeping such legacy behavior may be good idea. Adriano,
> what do you think?

I see. In 2.1 ib_util_malloc() simply uses standard malloc(). In 2.5
ib_util_malloc() uses a memory allocation function given by the engine
on ibutil initialization. In case initialization didn't commence, NULL
is returned. I guess your idea is to fall back to standard malloc() in
this case, counting on the fact that 2.5 engine always does the
initialization.

This will make libib_util from 2.5 work with 2.1 server and this would
be very good, making the server API backwards compatible.

--
dam

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: Firebird 3 ODS proposal for cache size

2009-12-15T06:34:19Z

On Tuesday 15 December 2009, Doug Chamberlin wrote:
> It has always been "easy" to change the config file. I'm asking for a
> scheme where it is unnecessary to make any changes. Set the per-server
> setting once and the default per-database setting once and then freely
> switch between CS and SS without any further changes. Or did I
> misunderstand?

But you can already set the per-database setting with gfix. What am I
missing?

Paul
--
Paul Reeves
----------------------------------------------------------------------------
--
I had a case a couple of months ago with a client, it is a vertical market
product and it uses FB as its back end. Gets installed in small sites.
They switched from SS to Classic as some of their coding / DB design
resulted in SS hanging for short periods.

They switched to Classic and it resolved their problem.

They then had a site with 25 seats with 2 connections per seat and a cache
setting of 10000 on a 4k page size. You can see where I am going with this
:-). The started to exhaust RAM and then have "hangs" for ages. The
setting was 100% appropriate for SS, but not for Classic.

No Paul may say (other Paul), that they are too daft to have a DB then
(extreme character assassination), but it is just another one of those
gotcha's that makes the environment seem complicated to newbies. I know it
does me out of work to reduce the learning curve.

Jason Chapman
JAC2 Consultancy
Training - Development - Consultancy
Delphi, InterBase, Firebird, OOAD, Development lifecycle assistance,
Troubleshooting projects, QA.....
Web: www.jac2.co.uk
Mob: (+44) 07966 211 959 (preferred)
Tel: (+44) 01928 751088
skype: jac2jac2

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: Firebird 3 ODS proposal for cache size

2009-12-15T06:30:16Z

On Tuesday 15 December 2009 17:18:44 Paul Reeves wrote:
> On Tuesday 15 December 2009, Doug Chamberlin wrote:
> > It has always been "easy" to change the config file. I'm asking for a
> > scheme where it is unnecessary to make any changes. Set the per-server
> > setting once and the default per-database setting once and then freely
> > switch between CS and SS without any further changes. Or did I
> > misunderstand?
>
> But you can already set the per-database setting with gfix. What am I
> missing?

Paul, the problem is need to change a lot of databases with gfix. For
per-database setting in aliases.conf life is much easier - just do

alias1 = /some/where/file1.fdb
{
include buffers.conf
}

alias2 = /some/where/else/file2.fdb
{
include buffers.conf
}

In buffers.conf you may have:
Buffers = 200
for Classic server. When changing to SS:
Buffers = 5000
i.e. just change single file.

But if we can have in it:
BuffersClassic = 200
BuffersSuper = 5000
life is even more easier.

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: Firebird 3 ODS proposal for cache size

2009-12-15T06:26:37Z

> On Tuesday 15 December 2009, Doug Chamberlin wrote:
> > It has always been "easy" to change the config file. I'm asking for a
> > scheme where it is unnecessary to make any changes. Set the per-server
> > setting once and the default per-database setting once and then freely
> > switch between CS and SS without any further changes. Or did I
> > misunderstand?
>
> But you can already set the per-database setting with gfix. What am I
> missing?

Tuning of page cache size is different for SuperServer and Classic Server. I don't think switching between CS and SS warrants a duplication of settings. Switching your application backend requires careful planning and testing, not haphazard experimentation and hoping the settings you (hopefully) configured in the past are still valid in the current context.

Mark
--
Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.!
http://portal.gmx.net/de/go/dsl02

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: Firebird 3 ODS proposal for cache size

2009-12-15T06:18:44Z

Re: Firebird 3 ODS proposal for cache size

2009-12-15T05:56:06Z

On Tuesday 15 December 2009 16:37:03 Doug Chamberlin wrote:

> Alexander Peshkoff wrote:
> > There will be per-database configuration in fb3 (in aliases.conf), and it
> > will be possible to set cache size in it. Combined with include directiev
> > in that file, I believe it will be easy to change thta setting when
> > server type changes.
>
> It has always been "easy" to change the config file. I'm asking for a
> scheme where it is unnecessary to make any changes. Set the per-server
> setting once and the default per-database setting once and then freely
> switch between CS and SS without any further changes. Or did I
> misunderstand?

This makes sense, please add a ticket to the tracker when it will be online
again.

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: Firebird 3 ODS proposal for cache size

2009-12-15T05:37:03Z

Alexander Peshkoff wrote:
> There will be per-database configuration in fb3 (in aliases.conf), and it will
> be possible to set cache size in it. Combined with include directiev in that
> file, I believe it will be easy to change thta setting when server type
> changes.

It has always been "easy" to change the config file. I'm asking for a
scheme where it is unnecessary to make any changes. Set the per-server
setting once and the default per-database setting once and then freely
switch between CS and SS without any further changes. Or did I
misunderstand?

--
Doug C.
-----
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: Testing Firebird-2.1.3 64bit on SPARC

2009-12-15T05:06:54Z

Vlad Khorsun-2 wrote:

> Thanks for patch

Does you tried it ?

Hi,

We applied you patch patch. It seems that our initial problem has been solved. Unfortunately we
encountered another Bus Error. The stack is the following:

#0 0x0000000100333a00 in Firebird::BePlusTree<Jrd::BlobIndex, unsigned int, Firebird::MemoryPool, Jrd::BlobIndex, Firebird::DefaultComparator<unsigned int>, 16, 375>::Accessor::getFirst (this=0xffffffff77105eb8)
at ../src/include/../common/classes/tree.h:483
#1 0x0000000100333adc in Firebird::BePlusTree<Jrd::BlobIndex, unsigned int, Firebird::MemoryPool, Jrd::BlobIndex, Firebird::DefaultComparator<unsigned int>, 16, 375>::getFirst (this=0xffffffff77105ea0)
at ../src/include/../common/classes/tree.h:197
#2 0x000000010032fb5c in TRA_release_transaction (tdbb=0xffffffff7a8fb658,
transaction=0xffffffff77105e70) at ../src/jrd/tra.cpp:1050
#3 0x0000000100332c20 in TRA_rollback (tdbb=0xffffffff7a8fb658,
transaction=0xffffffff77105e70, retaining_flag=false, force_flag=true)
at ../src/jrd/tra.cpp:1308
#4 0x000000010028f8f4 in purge_transactions (tdbb=0xffffffff7a8fb658,
attachment=0xffffffff7900c518, force_flag=true, att_flags=1040)
at ../src/jrd/jrd.cpp:7012
#5 0x0000000100290c3c in purge_attachment (tdbb=0xffffffff7a8fb658,
user_status=0xffffffff7a8fb4b0, attachment=0xffffffff7900c518,
force_flag=true) at ../src/jrd/jrd.cpp:7122
#6 0x0000000100292334 in shutdown_dbb (tdbb=0xffffffff7a8fb658,
dbb=0xffffffff7ca0ce88, released=0x0) at ../src/jrd/jrd.cpp:6591
#7 0x0000000100292550 in shutdown_all () at ../src/jrd/jrd.cpp:6652
#8 0x0000000100292718 in JRD_shutdown_all (asyncMode=false)
at ../src/jrd/jrd.cpp:6927
#9 0x00000001000d52f4 in shutdown_thread (arg=0x0)
at ../src/remote/inet_server.cpp:603
#10 0x000000010010b538 in (anonymous namespace)::ThreadArgs::run (
this=0xffffffff7a8fbf28) at ../src/jrd/ThreadData.cpp:274
#11 0x000000010010b198 in (anonymous namespace)::threadStart (
arg=0xffffffff7cb0fa80) at ../src/jrd/ThreadData.cpp:284
#12 0xffffffff7d8d6028 in _lwp_start () from /lib/64/libc.so.1
#13 0xffffffff7d8d6028 in _lwp_start () from /lib/64/libc.so.1

When I looked into assembler I noticed that there is attempt to load a number from
memory located at funny address 0xdeadbeefdeadbeef.

Regards

Pawel

Re: cross-version API/ABI stability of libib_util / posix

2009-12-15T01:46:08Z

On Monday 14 December 2009 23:42:42 Damyan Ivanov wrote:
> Hi,
>

> However, /usr/lib is version-agnostic, that means that a library there
> would be used by all server/client versions. This is known to not be
> a problem for libfbclient2 and (the client part of) libfembed (the
> classic server uses version-specific soname). I guess libib_util is
> also safe to use cross-version, but would like a confirmation.
>
> Is it safe to load libib_util.so from 2.5 into 2.1 server? Into 2.0
> server? And libib_util from 2.1 into 2.0?
>
> I hope the answer is yes. If not, I think the soname of libib_util
> shall be changed to reflect backward-incompatibility. (Note that is
> perfectly OK to say that 2.1 server needs libib_util of 2.1 or above).

The answer is unfortunately 'no'. It's internals never changed before 2.5, but
2.5 is change-point. I'm not absolutely sure, why did Adriano not change
soname, but I agree with him. Let me explain why.

The UDF side of API has not changed. I.e. any UDF which successfully worked
with ib_util in 2.1 and earlier version will continue correctly working with
libib_util from 2.5. But internals of libib_util did change, it has
additional entry point used by engine to initialize that library. To avoid
use of old libib_util, engine itself preloads libib_util before first call to
any UDF. And performs required initialization. In case when correct (having
initialization entry point) library can not be found/loaded, UDF is not
called, and user gets appropriate message, duplicated in firebird.log.

You may ask - but why all this complexity, if you can simply change soname?
There are 2 reasons. First, we anyway do not have such wonderful solution in
windows. Next (and may be the most important) - traditions. libib_util soname
did not change for >10 years, it's API did not change (and from UDF's POV
it's still unchanged), therefore many people could simply loose sources of
UDFs. Others may do not have src at all, if they use some commercial
FB/IB-based software with closed-source UDFs. We do not want additional
migration nightmare, therefore soname is kept unchanged.

What about your problem. I think the correct solution is to keep pre-2.5
libibutil as is (in /opt/firebird/lib), placing new libib_util into /usr/lib.
I do not suppose it's internals to be changed in the nearest 10 years :-)

It's technically possible (and very easy) to make libib_util have legacy
behavior if initialization was not done. Taking into an account, that
currently when ib_util_malloc() is called in not initialized library it's
anyway segfault for 99% of UDFs, I start to think that keeping such legacy
behavior may be good idea. Adriano, what do you think?

Alex.

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: Firebird 3 ODS proposal for cache size

2009-12-15T01:25:08Z

On Tuesday 15 December 2009 02:34:05 Doug Chamberlin wrote:

> As you know, the cache size configuration setting is different between
> CC and SS architectures. This causes problems when a site switches
> between CC and SS since it is one of the few items that really must be
> addressed in such a switch.
>
> In Firebird 3.0 I would like to propose that this be changed so that a
> given installation can freely switch between architectures without
> needing to change this setting at all.
>
> I'm not sure exactly how this should be done, but I'm sure you clever
> developers can find a way. Perhaps by introducing an additional value so
> that both the per-database and per-server cache settings are present in
> all locations. That way each architecture can use the one it wants and
> both can be set to reasonable values. (I'm bringing it up because it has
> been covered recently in the support list and since one of the locations
> for this setting is within each database, the solution may mean an ODS
> change and ODS changes have also been discussed recently here in the
> devel list.)

There will be per-database configuration in fb3 (in aliases.conf), and it will
be possible to set cache size in it. Combined with include directiev in that
file, I believe it will be easy to change thta setting when server type
changes.

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Firebird 3 ODS proposal for cache size

2009-12-14T15:34:05Z

As you know, the cache size configuration setting is different between
CC and SS architectures. This causes problems when a site switches
between CC and SS since it is one of the few items that really must be
addressed in such a switch.

In Firebird 3.0 I would like to propose that this be changed so that a
given installation can freely switch between architectures without
needing to change this setting at all.

I'm not sure exactly how this should be done, but I'm sure you clever
developers can find a way. Perhaps by introducing an additional value so
that both the per-database and per-server cache settings are present in
all locations. That way each architecture can use the one it wants and
both can be set to reasonable values. (I'm bringing it up because it has
been covered recently in the support list and since one of the locations
for this setting is within each database, the solution may mean an ODS
change and ODS changes have also been discussed recently here in the
devel list.)

This is a nagging issue that has been around for a long time and it
would sure be nice to have it disposed of so Firebird can again reach
its "low admin cost" goal.

--
Doug C.
-----
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

cross-version API/ABI stability of libib_util / posix

2009-12-14T12:42:42Z

Hi,

While working on Debian packages, I saw an opportunity to fix a big
filed against the 2.1 Debian package, namely
http://bugs.debian.org/524052 -- Home made UDF cannot use
libib_utils.so

The root of the problem with the package is that libib_util.so is not
shipped in /usr/lib.

In 2.5, I decided to give the standard directory layout a try. Thanks
to the new --with-xxx configure switches (thanks, Alex!), I was able
to tune the direcotries to my needs. Libraries can go to /usr/lib.
However, /usr/lib is version-agnostic, that means that a library there
would be used by all server/client versions. This is known to not be
a problem for libfbclient2 and (the client part of) libfembed (the
classic server uses version-specific soname). I guess libib_util is
also safe to use cross-version, but would like a confirmation.

Is it safe to load libib_util.so from 2.5 into 2.1 server? Into 2.0
server? And libib_util from 2.1 into 2.0?

I hope the answer is yes. If not, I think the soname of libib_util
shall be changed to reflect backward-incompatibility. (Note that is
perfectly OK to say that 2.1 server needs libib_util of 2.1 or above).

--
dam

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Broadview & Sean don't have e-mail

2009-12-14T09:02:14Z

sorry for dual posting this but Sean just called to say that
his email server is down. He'll send mail when it's back.

Best,

Ann

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: xnet connect failures in 2.0.5 and 2.1.3

2009-12-14T08:43:46Z

> -----Original Message-----
> From: Vlad Khorsun [mailto:hvlad@...]
> Sent: Monday, December 14, 2009 10:29 AM
> To: For discussion among Firebird Developers
> Subject: Re: [Firebird-devel] xnet connect failures in 2.0.5 and 2.1.3
>
> > I've been working with Paul Beach tracking down some xnet client
> connect problems that
> > seems to only be affecting slower windows 'server' machines (P4
> 2.6/2.8ghz, 512mb ram,
> > non hyperthreaded), one led to:
> >
> > http://tracker.firebirdsql.org/browse/CORE-2769

...<SNIP>
> > The response.map_num is XNET_INVALID_MAP_NUM and the client errors
> out. Once a timeout
> > happens no further XNET connections can be made until the server is
> restarted as each client will
> > grab the previous clients event.
>
> Very good explanation. Could you please post it into the tracker
> (as new ticket of course) ?

Sure can, I wanted to avoid doing that before getting some feedback.

> > The main reason I'm posting this is just to make sure that the
> details are understood in case there
> > is any reason to fix the timeout handling. I would think that this
> connection logic could be improved
> > if the client was setting an event (or the like) so that the server
> would realize the client timed out and
> > not set the xnet_response_event. Perhaps that's oversimplified, just
> an idea.
> >
> > This may all be moot with 2.5, and I'd understand not spending time
> on older versions for a problem
> > that likely affects few people.
>
> Anyway, bug should be fixed, IMHO.

I agree, however I have no idea what's going on in the bigger picture.

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: xnet connect failures in 2.0.5 and 2.1.3

2009-12-14T07:28:57Z

> I've been working with Paul Beach tracking down some xnet client connect problems that
> seems to only be affecting slower windows 'server' machines (P4 2.6/2.8ghz, 512mb ram,
> non hyperthreaded), one led to:
>
> http://tracker.firebirdsql.org/browse/CORE-2769
>
> However that particular change is a workaround to the actual problem discovered. I believe
> that the handling of XNET connection could be improved for classic server (I do not think this
> applies to superserver).
>
> When the client times out waiting for xnet_response_event, the client exits clean. The server
> however continues on and sets the xnet_response_event. This event sits out there for the next
> client who happily 'grabs' onto it and thinks a connection has been established.
> The response.map_num is XNET_INVALID_MAP_NUM and the client errors out. Once a timeout
> happens no further XNET connections can be made until the server is restarted as each client will
> grab the previous clients event.

Very good explanation. Could you please post it into the tracker (as new ticket of course) ?

> The main reason I'm posting this is just to make sure that the details are understood in case there
> is any reason to fix the timeout handling. I would think that this connection logic could be improved
> if the client was setting an event (or the like) so that the server would realize the client timed out and
> not set the xnet_response_event. Perhaps that's oversimplified, just an idea.
>
> This may all be moot with 2.5, and I'd understand not spending time on older versions for a problem
> that likely affects few people.

Anyway, bug should be fixed, IMHO.

> Last week I discovered that the xnet connect errors we're seeing in 2.1.3 are not all related to the timeout.
> There is something else that results in the same symptom (continual XNET errors 'Server failed to respond
> on connect request') requiring a restart of FB. I'm going to try and track this down to something specific
> over the next couple of days. Any suggestions would be very appreciated.

I have no quick ideas, sorry

Regards,
Vlad

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

xnet connect failures in 2.0.5 and 2.1.3

2009-12-14T06:40:14Z

I've been working with Paul Beach tracking down some xnet client connect problems that seems to only be affecting slower windows 'server' machines (P4 2.6/2.8ghz, 512mb ram, non hyperthreaded), one led to:

http://tracker.firebirdsql.org/browse/CORE-2769

However that particular change is a workaround to the actual problem discovered. I believe that the handling of XNET connection could be improved for classic server (I do not think this applies to superserver).

When the client times out waiting for xnet_response_event, the client exits clean. The server however continues on and sets the xnet_response_event. This event sits out there for the next client who happily 'grabs' onto it and thinks a connection has been established. The response.map_num is XNET_INVALID_MAP_NUM and the client errors out. Once a timeout happens no further XNET connections can be made until the server is restarted as each client will grab the previous clients event.

The main reason I'm posting this is just to make sure that the details are understood in case there is any reason to fix the timeout handling. I would think that this connection logic could be improved if the client was setting an event (or the like) so that the server would realize the client timed out and not set the xnet_response_event. Perhaps that's oversimplified, just an idea.

This may all be moot with 2.5, and I'd understand not spending time on older versions for a problem that likely affects few people.

Last week I discovered that the xnet connect errors we're seeing in 2.1.3 are not all related to the timeout. There is something else that results in the same symptom (continual XNET errors 'Server failed to respond on connect request') requiring a restart of FB. I'm going to try and track this down to something specific over the next couple of days. Any suggestions would be very appreciated.

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: Backporting data

2009-12-14T01:12:26Z

> -----Original Message-----
> From: Lester Caine [mailto:lester@...]
> Sent: Martes, 01 de Diciembre de 2009 6:02
>
> I have a number of sites currently that have FB1.5 on, and it
> will be some time
> before the machines are due for renewal, which is the only
> time they will be
> upgraded. FB2.1.2 is my current upgrade point having skipped
> FB2.0 and all the
> machines here run that, but I have a FB1.5 gbak on the system
> so that I can pull
> data from site - play with it - and then in an emergency -
> push it back to site.
>
> We are not talking about 'new features' since the database
> schema is always the
> older version, but is there anything stopping a version of
> gbak being made
> available which WOULD handle a backport from FB2.5 to
> something earlier?

gbak is not that simple as some people think:

- It handles native and portable backups.

- It should restore in a way that the server doesn't choke with the
depedencies among objects.

- It tries has to backup metadata and (by default, but optionally) data.

- It needs to know the source db's ODS when backing up: if it tries to read
a system table that doesn't exist, it will get an error and the backup is
aborted. For example, rdb$roles didn't exist in IB4; rdb$field_precision
didn't exist in IB5; rdb$roles and rdb$generators didn't have a
rdb$description column in FB1.5; there's no rdb$relation_type in
rdb$relations in FB2.0; rdb$messages was 255 in FB1.5 and before, 1021 in
FB2.0 and FB2.1 and 1023 in FB2.5; table rdb$packages only exists since
FB3.0 and so on.

- Since the beginning, gbak had the concept of RESTORE_format. This is the
same backup version number that was used when backing up. It's not 1:1 with
the server versions. For example, gbak for FB1 and FB1.5 have version 6
because system tables weren't enhanced between FB1 and FB1.5, new data types
weren't created and db-wide settings weren't introduced (SQL dialect was put
in the db header in IB6/FB1 and must be backed up). You know what you can
store in each backup version, hence if some tag is unrecognized or it's
recognized but didn't exist in such backup level (version), we have a
corrupt backup. I've tried to do all the possible checks to avoid garbage
being accepted as valid. For example, a backup produced with FB1's gbak is
version 6. If FB2.1's gbak tries to restore that backup in a FB2.1 server
and finds a tag for rdb$relation_type, it's valid for gbak_2.1 but is
invalid for that backup file, since such tag was introduced in FB2.1 and
gbak in FB1 couldn't have produced it. This means that backup is corrupt.

- When restoring, gbak always assumed it was using the same server version
as itself. This is not true if you are trying to downgrade the db through a
backup and therefore I introduced the value RESTORE_ods in FB2.1. When
restoring, gbak creates a db and can ask the server immediately what ODS
version it created. RESTORE_ods is the ODS supported by the target server
when restoring. If I have a backup of a system table or system field that
didn't exist in that older ODS, I should skip it. The feature complicates
the code and -as Alex as pointed out privately- is of very limited use
because gbak doesn't analyze BLR thus it won't discard unknown BLR verbs in
previous server versions. Procedures that use new BLR verbs won't compile on
older servers. Only data can be downgraded. I did a few tests years ago and
had some success with a FB2.1 backup restored with gbak 2.1 against FB2.0,
but when I tried to do the same from FB2.5 to FB2.1 some monts ago, I found
problems because security classes handling was changed in gbak in v2.5 and
in the server, the name generation logic for security classes was changed,
too. I seem to remember that I found some data that didn't fit in one of the
gbak variables.

- The other path is to use FB1.5 gbak to connect to FB2.1 and do a backup. I
think it won't work, because gbak 1.5 is compiled statically to handle the
field lengths that it knows in FB1.5, but some fields were enlarged in FB2.0
and newer and thus we'll see a nice string truncation message. If you were
able to finish the backup, probably the data would be valid to do a restore
on FB1.5, since gbak is the same version.

Probably not what you wanted to hear.
Save the new server's db's metadata in a script, tweak it to the old server,
keep it in a safe place and pump the data from the new to the old server
when you need it.

C.

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: Problem with tracing - still

2009-12-14T00:56:04Z

On Sunday 13 December 2009 00:41:30 Milan Babuskov wrote:

> You hit the nail here. As you can see, all the files have
> firebird:firebird permissions except one:
>
> fb_trace.{EE0FB4AD-E9B1-341B-8894-981CF377F5CC}.0000000
>
> and that one is set to be owned by root:root. When I manually change
> it to be owned by firebird:firebird, then the tracing works :)
>
> > What is kind of connection do you use - local (embedded) or via TCP/IP
> > ?
>
> TCP/IP
>
> > Could you try with local connection ?
>
> I just tried. Same problem.

Milan, as I can see from your first mail, you use embedded connection.

> root@milanb:/# /opt/firebird/bin/fbsvcmgr service_mgr
> action_trace_start trc_name "My trace" trc_cfg ./fbtrace.conf

Please try TCP one:

/opt/firebird/bin/fbsvcmgr localhost:service_mgr user sysdba password masterke
action_trace_start trc_name "My trace" trc_cfg ./fbtrace.conf

to make sure this is the reason.

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: Nitpicking

2009-12-13T10:26:24Z

Milan Babuskov wrote:
> On Sun, Dec 13, 2009 at 8:22 AM, Dmitry Yemanov <firebird2@...> wrote:
>> Yet another reason to make system tables not just read only in v3.0 but
>> also prohibit DDL statements against them.
>
> Does this mean we will no longer be able to use DELETE FROM
> MON$STATEMENTS WHERE... to stop a running query?
>
No, it does not mean that.

DDL should be disallowed in all system tables. DML should be disallowed
in all system tables, except some specific commands in some monitoring
tables, like one you mentioned.

Adriano

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: Nitpicking

2009-12-13T09:19:08Z

On Sun, Dec 13, 2009 at 8:22 AM, Dmitry Yemanov <firebird2@...> wrote:
> Yet another reason to make system tables not just read only in v3.0 but
> also prohibit DDL statements against them.

Does this mean we will no longer be able to use DELETE FROM
MON$STATEMENTS WHERE... to stop a running query?

Thanks,

--
Milan Babuskov
http://www.flamerobin.org

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: Nitpicking

2009-12-12T23:22:01Z

Claudio Valderrama C. wrote:

> Aberrations in FB3. :-)
>
> SQL> set term ^;
> SQL> alter table mon$memory_usage add constraint z check(mon$stat_group<
> 0);
> SQL> create exception e 'x'^
> SQL> create trigger tr for mon$memory_usage before insert as begin exception
> e; end^
> SQL> select mon$stat_group from mon$memory_usage^
>
> MON$STAT_GROUP
> ==============
> 0
> ....
>
> Fortunately, neither the check constraint nor the trigger are acknowledged.

Yet another reason to make system tables not just read only in v3.0 but
also prohibit DDL statements against them.

Dmitry

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[FB-Tracker] Created: (CORE-2808) XNET classic server client connection process timeout failure blocks subsequent connect attempts.

2009-12-12T23:10:34Z

XNET classic server client connection process timeout failure blocks subsequent connect attempts.
-------------------------------------------------------------------------------------------------

Key: CORE-2808
URL: http://tracker.firebirdsql.org/browse/CORE-2808
Project: Firebird Core
Issue Type: Bug
Components: Engine
Affects Versions: 2.0.5
Environment: Windows XP, for me problem only happens on slower machines, Pentium 4, 512mb ram, NON hyperthreader/multicore.
Reporter: Brenden Walker

When the client times out waiting for xnet_response_event, the client exits clean. The server however continues on and sets the xnet_response_event.

This event sits out there for the next client who happily 'grabs' onto it and thinks a connection has been established. The response.map_num is XNET_INVALID_MAP_NUM and the client errors out. Once a timeout happens no further XNET connections can be made until the server is restarted as each client will grab the previous clients event.

I've seen similar symptoms on 2.1.3, however the cause in the cases I've been able to adequately review has not been due to exceeding xnet_connect_timeout. When I get more information on that I'll post a new issue.

Workaround for this particular problem is to increase the timeout via new config file parameter created in http://tracker.firebirdsql.org/browse/CORE-2769

--
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

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[FB-Tracker] Created: (CORE-2807) Problem with tracing on linux

2009-12-12T20:39:34Z

Problem with tracing on linux
-----------------------------

Key: CORE-2807
URL: http://tracker.firebirdsql.org/browse/CORE-2807
Project: Firebird Core
Issue Type: Bug
Environment: posix
Reporter: Alexander Peshkov

Report ed in devel by Milan Babuskov.

Trace, started embedded, prevents remote attachments to SC server. With fbtrace.conf:
<database>
enabled true
log_statement_prepare true
log_statement_free true
log_statement_start true
log_statement_finish true
time_threshold 0
</database>
as root:

root@milanb:/# /opt/firebird/bin/fbsvcmgr service_mgr
action_trace_start trc_name "My trace" trc_cfg ./fbtrace.conf

makes it impossible to attach to server:
------------------------------------------
SQL Message : -902
Unsuccessful execution caused by a system error that precludes
successful execution of subsequent statements

Engine Code : 335544373
Engine Message :
operating system directive write failed
Bad file descriptor
------------------------------------------

When tracing is not running, everything works fine.

--
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

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[FB-Tracker] Created: (CORE-2806) Views based on procedures can't be created if the proc's output fields participate in an expression

2009-12-12T18:12:34Z

Views based on procedures can't be created if the proc's output fields participate in an expression
---------------------------------------------------------------------------------------------------

Key: CORE-2806
URL: http://tracker.firebirdsql.org/browse/CORE-2806
Project: Firebird Core
Issue Type: Bug
Components: Engine
Affects Versions: 2.5 RC1, 3.0 Initial, 2.5 Beta 2
Reporter: Claudio Valderrama C.

While testing my extensions to table rdb$view_relations to close an ambiguity in the definition of views based on procedures, I found this:

F:\fb3dev\fbbuild\firebird30\temp\Win32\Debug\firebird\bin>isql
Use CONNECT or CREATE DATABASE to specify a database
SQL> create database 'procview.fdb';
SQL> set term ^;
SQL> create procedure p returns(rc int) as begin rc = 1; suspend; end^
SQL> create view v2(dosrc) as select rc * 2 from p^
Statement failed, SQLSTATE = HY000
invalid request BLR at offset 3
-context not defined (BLR error)

--
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

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[FB-Tracker] Created: (CORE-2805) Allow to remotely clear the log file

2009-12-12T17:38:35Z

Allow to remotely clear the log file
------------------------------------

Key: CORE-2805
URL: http://tracker.firebirdsql.org/browse/CORE-2805
Project: Firebird Core
Issue Type: Improvement
Components: API / Client Library, Engine
Reporter: Douglas Tosi

Currently a client can only read the log file (firebird.log) via ServicesAPI.

Please add a service action that clears the log file. This reduces the need to log in to the server to perform common maintenance.

--
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

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[FB-Tracker] Created: (CORE-2804) The problems with [COMMENT ON table IS 'russian text'] and markers of charsets

2009-12-12T16:36:35Z

The problems with [COMMENT ON table IS 'russian text'] and markers of charsets
------------------------------------------------------------------------------

Key: CORE-2804
URL: http://tracker.firebirdsql.org/browse/CORE-2804
Project: Firebird Core
Issue Type: Bug
Affects Versions: 2.5 RC1
Reporter: Kovalenko Dmitry

Server Version 2.5.0.25856

------- TEST1
Connection with NONE charset

When I run the
comment on TABLE dual is _win1251 'russian text'
Server returns the "malformed string". Here 'russian text' in win1251 charset

When I run the
comment on TABLE dual is _unicode_fss 'russian text'
Server returns OK. Here 'russian text' in UNICODE_FSS charset

------- TEST2
Connection with WIN1251 charset

When I run the
comment on TABLE dual is _win1251 'russian text'
Server returns OK.

When I run the
comment on TABLE dual is _unicode_fss 'russian text in UTF8 charset'
Server returns OK. But writes in system table the text with wrong charset

--
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

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[FB-Tracker] Created: (CORE-2803) Views based on procedures shouldn't accept WITH CHECK OPTION

2009-12-12T16:02:41Z

Views based on procedures shouldn't accept WITH CHECK OPTION
------------------------------------------------------------

Key: CORE-2803
URL: http://tracker.firebirdsql.org/browse/CORE-2803
Project: Firebird Core
Issue Type: Bug
Components: Engine
Affects Versions: 3.0 Initial, 2.5 Beta 2, 2.5 RC1, 2.5 RC2
Reporter: Claudio Valderrama C.

F:\fb3dev\fbbuild\firebird30\temp\Win32\Debug\firebird\bin>isql
Use CONNECT or CREATE DATABASE to specify a database
SQL> create database 'procview.fdb';
SQL> set term ^;
SQL> create procedure p returns(rc int) as begin rc = 1; suspend; end^
SQL> select * from p^

RC
============
1

SQL> create view v as select rc from p where rc > 0^
SQL> create view v2 as select rc from p where rc > 0 with check option^
Statement failed, SQLSTATE = 42S02
Dynamic SQL Error
-SQL error code = -204
-Table unknown
-P
-At line 0, column 0

You can't insert into a procedure or update its returned rows, so the check option doesn't make sense.

--
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

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: Problem with tracing - still

2009-12-12T13:41:30Z

On Sat, Dec 12, 2009 at 5:19 PM, Vlad Khorsun
<hvlad@...> wrote:
> I'm not an Linux-man but i'll try to help. Alex for sure could do it better than me.

Thanks Vlad.

> Could you verify if /tmp/firebird/fb_trace file was created at this point ?

Yes, it creates /tmp/firebird and the following files:

milanb@milanb:/tmp$ ls -l firebird/
total 16
-rw-rw---- 1 firebird firebird 0 2009-12-12 22:40 fb_init
-rw-rw---- 1 firebird firebird 4136 2009-12-12 22:40 fb_trace
-rw-rw---- 1 firebird firebird 32 2009-12-12 22:40
fb_trace.{EE0FB4AD-E9B1-341B-8894-981CF377F5CC}
-rw------- 1 root root 0 2009-12-12 22:40
fb_trace.{EE0FB4AD-E9B1-341B-8894-981CF377F5CC}.0000000
-rw-rw---- 1 firebird firebird 398 2009-12-12 22:40 fb_trace_zRZZck

> If you found this file, please, check permissions on it and on /firebird
> sub-folder. It should allow full access for members of "firebird" group.

You hit the nail here. As you can see, all the files have
firebird:firebird permissions except one:

fb_trace.{EE0FB4AD-E9B1-341B-8894-981CF377F5CC}.0000000

and that one is set to be owned by root:root. When I manually change
it to be owned by firebird:firebird, then the tracing works :)

> What is kind of connection do you use - local (embedded) or via TCP/IP ?

TCP/IP

> Could you try with local connection ?

I just tried. Same problem.

Thanks for quick reply.

--
Milan Babuskov
http://www.flamerobin.org

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: Problem with tracing - still

2009-12-12T13:16:58Z

Vlad Khorsun wrote:

>> I just downloaded and installed RC1 on Linux (32bit, Classic), and I
>> still have the same problems with tracing.
>
> I'm not an Linux-man but i'll try to help. Alex for sure could do it better than me.

I'd also suggest to try the snapshot build instead of the RC1 ;-)

Dmitry

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: Problem with tracing - still

2009-12-12T08:19:41Z

> I just downloaded and installed RC1 on Linux (32bit, Classic), and I
> still have the same problems with tracing.

I'm not an Linux-man but i'll try to help. Alex for sure could do it better than me.

> root@milanb:/# /opt/firebird/bin/fbsvcmgr -Z
> Firebird services manager version LI-V2.5.0.25784 Firebird 2.5 Release
> Candidate 1
>
> Here is the fbtrace.conf:
>
> root@milanb:/# cat fbtrace.conf
> <database>
> enabled true
> log_statement_prepare true
> log_statement_free true
> log_statement_start true
> log_statement_finish true
> time_threshold 0
> </database>
>
> I run it from command line like this:
>
> root@milanb:/# /opt/firebird/bin/fbsvcmgr service_mgr
> action_trace_start trc_name "My trace" trc_cfg ./fbtrace.conf

Could you verify if /tmp/firebird/fb_trace file was created at this point ?

I'm not sure if firebird/fb_trace is really located at /tmp so look at correct
"temporary" folders at your system (maybe /var ?).

If you found this file, please, check permissions on it and on /firebird
sub-folder. It should allow full access for members of "firebird" group.

> Next, I use some client application to connect to some database. When
> I try to connect to *any* database, I get this error:
>
> ------------------------------------------
> SQL Message : -902
> Unsuccessful execution caused by a system error that precludes
> successful execution of subsequent statements
>
> Engine Code : 335544373
> Engine Message :
> operating system directive write failed
> Bad file descriptor
> ------------------------------------------

What is kind of connection do you use - local (embedded) or via TCP/IP ?

> When tracing is not running, everything works fine.
>
> When I try with isql, I get this:
>
> milanb@milanb:~$ /opt/firebird/bin/isql
> localhost:/opt/firebird/examples/empbuild/employee.fdb -user sysdba
> -pass ****
> Statement failed, SQLSTATE = HY000
> operating system directive write failed
> -Bad file descriptor
> Use CONNECT or CREATE DATABASE to specify a database
> SQL> exit;

Could you try with local connection ?

> My system configuration is:
>
> milanb@milanb:~$ cat /etc/slackware-version
> Slackware 12.0.0
> milanb@milanb:~$ uname -a
> Linux milanb 2.6.21.5-smp #2 SMP Tue Jun 19 14:58:11 CDT 2007 i686
> Intel(R) Pentium(R) III Mobile CPU 1000MHz GenuineIntel GNU/Linux
>
> Is tracing supposed to work on Linux?

Sure. It should work and we tested it and it passed tests at least at dev machines.
Else we didn't release RC1.

Regards,
Vlad

PS You could try snapshot also. It is much more fresh than outdated RC1. Also you
will find updated documentation for trace there. New fbtracemgr utility is also
documented now.

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Problem with tracing - still

2009-12-12T06:58:57Z

Hi,

I just downloaded and installed RC1 on Linux (32bit, Classic), and I
still have the same problems with tracing.

root@milanb:/# /opt/firebird/bin/fbsvcmgr -Z
Firebird services manager version LI-V2.5.0.25784 Firebird 2.5 Release
Candidate 1

Here is the fbtrace.conf:

root@milanb:/# cat fbtrace.conf
<database>
enabled true
log_statement_prepare true
log_statement_free true
log_statement_start true
log_statement_finish true
time_threshold 0
</database>

I run it from command line like this:

root@milanb:/# /opt/firebird/bin/fbsvcmgr service_mgr
action_trace_start trc_name "My trace" trc_cfg ./fbtrace.conf

Next, I use some client application to connect to some database. When
I try to connect to *any* database, I get this error:

------------------------------------------
SQL Message : -902
Unsuccessful execution caused by a system error that precludes
successful execution of subsequent statements

Engine Code : 335544373
Engine Message :
operating system directive write failed
Bad file descriptor
------------------------------------------

When tracing is not running, everything works fine.

When I try with isql, I get this:

milanb@milanb:~$ /opt/firebird/bin/isql
localhost:/opt/firebird/examples/empbuild/employee.fdb -user sysdba
-pass ****
Statement failed, SQLSTATE = HY000
operating system directive write failed
-Bad file descriptor
Use CONNECT or CREATE DATABASE to specify a database
SQL> exit;

My system configuration is:

milanb@milanb:~$ cat /etc/slackware-version
Slackware 12.0.0
milanb@milanb:~$ uname -a
Linux milanb 2.6.21.5-smp #2 SMP Tue Jun 19 14:58:11 CDT 2007 i686
Intel(R) Pentium(R) III Mobile CPU 1000MHz GenuineIntel GNU/Linux

Is tracing supposed to work on Linux?

Thanks,

--
Milan Babuskov
http://www.flamerobin.org

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Nitpicking

2009-12-12T05:50:52Z

Aberrations in FB3. :-)

SQL> set term ^;
SQL> alter table mon$memory_usage add constraint z check(mon$stat_group <
0);
SQL> create exception e 'x'^
SQL> create trigger tr for mon$memory_usage before insert as begin exception
e; end^
SQL> select mon$stat_group from mon$memory_usage^

MON$STAT_GROUP
==============
0
....

Fortunately, neither the check constraint nor the trigger are acknowledged.

C.
---
Claudio Valderrama C. - www.cvalde.net
Consultant, SW developer.

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: 2.5 RC1 and WOW64

2009-12-12T05:03:38Z

On Sat, Dec 12, 2009 at 6:48 AM, Roman Simakov <roman.simakov@...> wrote:
> or win32 zip too :)

That's what I did. Thanks Roman and Sean.
My point is that it would be 'handy' to also have the 32bit client on
the 64bit zip.

Regards,
--
Douglas Tosi
www.sinatica.com

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel