On 02/13/12 21:21, Dimitry Sibiryakov wrote:
> 13.02.2012 16:08, Dmitry Yemanov wrote:
>> Interesting idea. But how should the conditions like (offset< 0) look
>> now? Something like (offset< sizeof(lhb)) doesn't look elegant. Maybe
>> explicitly compare with all the magic numbers?
>How abou
13.02.2012 16:08, Dmitry Yemanov wrote:
> Interesting idea. But how should the conditions like (offset< 0) look
> now? Something like (offset< sizeof(lhb)) doesn't look elegant. Maybe
> explicitly compare with all the magic numbers?
How about (offset < MAX_MAGIC_NUMBER)?
--
SY, SD.
13.02.2012 13:45, Alex Peshkoff wrote:
>> I'm not really sure this is strictly required for v2.x. We surely must
>> add an overflow protection, here I agree.
>
> A check in shared memory grow code should do a trick.
Sure.
>> But if it would be possible to
>> have ULONG offsets instead of SLONG,
13.02.2012 14:13, Vlad Khorsun wrote:
> Imagine x64 CS server and x32 embedded apps at the same time.
> They must share the same lock table...
It was never possible. 64-bit lock table is incompatible with 32-bit one
and it has different version number in the header.
Dmitry
---
13.02.2012 11:37, Alex Peshkoff wrote:
> Later we have plans to have pluggable lock manager, making it possible
> to tune installation.
I don't like the idea to put whole responsibility to DBA because it is hard
to predict
when such tuning may be required.
How about keep 32bits offset, but
On 02/13/12 13:19, Dimitry Sibiryakov wrote:
> 13.02.2012 9:06, Dmitry Yemanov wrote:
>> 13.02.2012 11:51, Nikolay Samofatov wrote:
Taking into an account that most of users do not need>2Gb of lock
table, 64-bit offsets (at least for 2.5) should better remain tunable
build parameter
> 11.02.2012 20:03, marius adrian popa wrote:
>
>> I will respond for 2) at first changing the offsets to 64bit doesn't
>> look too hard replace SLONG with SINT64
>> in the lock.cpp functions
>> but i might be wrong so i leave the core dev if is easy
>
> First of all, this must be conditional de
On 02/13/12 11:53, Dmitry Yemanov wrote:
> 13.02.2012 11:39, Alex Peshkoff wrote:
>
>> The simplest part of the task. Just make them offset_t - very logical
>> name for offsets :-)
> It depends on what headers you include. For example, our own offset_t
> defined in File.h is always 64-bit :-)
>
13.02.2012 9:06, Dmitry Yemanov wrote:
> 13.02.2012 11:51, Nikolay Samofatov wrote:
>>
>>> Taking into an account that most of users do not need>2Gb of lock
>>> table, 64-bit offsets (at least for 2.5) should better remain tunable
>>> build parameter, turned off by default.
>>
>> Great idea, BTW. I
13.02.2012 11:51, Nikolay Samofatov wrote:
>
>> Taking into an account that most of users do not need>2Gb of lock
>> table, 64-bit offsets (at least for 2.5) should better remain tunable
>> build parameter, turned off by default.
>
> Great idea, BTW. I haven't thought of a build parameter.
I can a
13.02.2012 11:39, Alex Peshkoff wrote:
> The simplest part of the task. Just make them offset_t - very logical
> name for offsets :-)
It depends on what headers you include. For example, our own offset_t
defined in File.h is always 64-bit :-)
> Certainly, a lot of places where lock size is calc
Alex,
> Taking into an account that most of users do not need>2Gb of lock
> table, 64-bit offsets (at least for 2.5) should better remain tunable
> build parameter, turned off by default.
Great idea, BTW. I haven't thought of a build parameter.
Nikolay Samofatov
-
Dmitry,
On 11.02.2012 20:15, Dmitry Yemanov wrote:
> 11.02.2012 20:03, marius adrian popa wrote:
>
>> I will respond for 2) at first changing the offsets to 64bit doesn't
>> look too hard replace SLONG with SINT64
>> in the lock.cpp functions
>> but i might be wrong so i leave the core dev if is
On 02/11/12 20:15, Dmitry Yemanov wrote:
> 11.02.2012 20:03, marius adrian popa wrote:
>
>> I will respond for 2) at first changing the offsets to 64bit doesn't
>> look too hard replace SLONG with SINT64
>> in the lock.cpp functions
>> but i might be wrong so i leave the core dev if is easy
> Fir
Em 11/2/2012 19:19, Carlos H. Cantu escreveu:
> SM> Sorry, I have no solution for this situation, but I`m curious - what
> SM> is the Oracle price for such kind of configurations/projects?
>
> Well, probably a bunch of money!
>
> This leads me to think: a customer who saved so much money using FB
SM> Sorry, I have no solution for this situation, but I`m curious - what
SM> is the Oracle price for such kind of configurations/projects?
Well, probably a bunch of money!
This leads me to think: a customer who saved so much money using FB
would be more than welcome to become platinum sponsor for
On Sat, Feb 11, 2012 at 6:50 PM, Sergey Mereutsa wrote:
> Hi!
>
> NS> Mem: 529177288k total, 378587600k used, 150589688k free, 761532k
> buffers
> ...
> NS> -rw-rw 1 root root 453031493632 Feb 11 03:26 ncore-mvv.fdb
>
>
> Sorry, I have no solution for this situation, but I`m curious - what
Hi!
NS> Mem: 529177288k total, 378587600k used, 150589688k free, 761532k buffers
...
NS> -rw-rw 1 root root 453031493632 Feb 11 03:26 ncore-mvv.fdb
Sorry, I have no solution for this situation, but I`m curious - what
is the Oracle price for such kind of configurations/projects?
I`m reall
11.02.2012 20:03, marius adrian popa wrote:
> I will respond for 2) at first changing the offsets to 64bit doesn't
> look too hard replace SLONG with SINT64
> in the lock.cpp functions
> but i might be wrong so i leave the core dev if is easy
First of all, this must be conditional depending on t
On Sat, Feb 11, 2012 at 2:59 AM, Nikolay Samofatov
wrote:
> Hello, All!
>
> We run Firebird to power larger systems (for 12 government agencies and 3
> banks).
>
> We have had pretty spectacular crash on one of our systems today.
>
> It has approximately 10 end users multiplexed through 2500
Hello, All!
We run Firebird to power larger systems (for 12 government agencies and 3
banks).
We have had pretty spectacular crash on one of our systems today.
It has approximately 10 end users multiplexed through 2500 (max) pooled
connections.
Here is the snapshot of nearly idle system a
21 matches
Mail list logo
