Yi Lu [2012-01-03 02:02] :
> Also, we would be willing to contribute to the Firebird foundation in order
> to help us to develop this feature as we can't wait until Firebird 3.0.
Please contact me directly, to see what are your need and willing so we
can find the best solution
--
Philippe Makow
>
> 1. hdr_oldest_transaction, hdr)oldest_active, hdr_next_transaction on
> header_page structure should be SINT64 on file ods.h.
> 2. fld_trans_id should have dtype_int64 and size should be sizeof(SINT64) on
Why signed?
Ann
>
--
We are trying to take the approach #1, involving ODS change and data type
changes for transaction id to use signed 64 bit integer. We just start
looking at the code from today and following changes should be applied on
code changes so far,
1. hdr_oldest_transaction, hdr)oldest_active, hdr_next_tran
Dimitry Sibiryakov wrote:
>> In my own cases, ANY downtime during office hours is unacceptable, so any
>> > failure that brings the whole system down would result in penalties!
>> > Organised
>> > downtime is possible on many sites, but some sites are running 24/7, So we
>> > maintain data in a
On Mon, Jan 2, 2012 at 2:32 PM, Yi Lu wrote:
> Approach 1 seems to be least risky. Disk space should not be a big issue with
> today's hardware.
>
The problem is not disk space, but locality of reference. With small
records, adding
four bytes could decrease the number of rows per page by 10-15%,
We turn off the automatical sweep option, and manually perform sweep (as well
as recompute index selectivity) once a day at low hour (2am). The
performance is actually not impacted so much.
--
View this message in context:
http://firebird.1100200.n4.nabble.com/Firebird-Transaction-ID-limit-soluti
Approach 1 seems to be least risky. Disk space should not be a big issue with
today's hardware.
--
View this message in context:
http://firebird.1100200.n4.nabble.com/Firebird-Transaction-ID-limit-solution-tp4230210p4254287.html
Sent from the firebird-devel mailing list archive at Nabble.com.
--
02.01.2012 17:40, Lester Caine wrote:
> In my own cases, ANY downtime during office hours is unacceptable, so any
> failure that brings the whole system down would result in penalties! Organised
> downtime is possible on many sites, but some sites are running 24/7, So we
> maintain data in a manor
Dimitry Sibiryakov wrote:
>> Could you stop with the absurd comparisons? One is normal maintenance
>> > and the other is (extreme) disaster recovery which are in no way
>> > comparable.
> But downtime is downtime. Customers don't care about its reason, do
> they?..
In my own cases, ANY down
On 2-1-2012 16:43, Dimitry Sibiryakov wrote:
> 02.01.2012 16:10, Mark Rotteveel wrote:
>> Could you stop with the absurd comparisons? One is normal maintenance
>> and the other is (extreme) disaster recovery which are in no way comparable.
>
> But downtime is downtime. Customers don't care abou
Mark Rotteveel wrote:
>> 02.01.2012 14:46, Jesus Garcia wrote:
>>> >> he problem is not downtime is how much downtime. Backup and restore is
>>> >> so much downtime.
>> >
>> > Not more downtime that simple restore after complete server
>> > destruction by flood or
>> > plane crash.
> Coul
02.01.2012 16:10, Mark Rotteveel wrote:
> Could you stop with the absurd comparisons? One is normal maintenance
> and the other is (extreme) disaster recovery which are in no way comparable.
But downtime is downtime. Customers don't care about its reason, do they?..
--
SY, SD.
---
On 2-1-2012 15:50, Dimitry Sibiryakov wrote:
> 02.01.2012 14:46, Jesus Garcia wrote:
>> he problem is not downtime is how much downtime. Backup and restore is so
>> much downtime.
>
> Not more downtime that simple restore after complete server destruction
> by flood or
> plane crash.
Could y
02.01.2012 14:46, Jesus Garcia wrote:
> he problem is not downtime is how much downtime. Backup and restore is so
> much downtime.
Not more downtime that simple restore after complete server destruction by
flood or
plane crash.
--
SY, SD.
---
>
> Single server without downtime is a myth anyway.
The problem is not downtime is how much downtime. Backup and restore is so much
downtime.
Jesus
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a
01.01.2012 23:43, Kjell Rilbe wrote:
> Den 2012-01-01 23:25 skrev Dimitry Sibiryakov såhär:
>> 01.01.2012 21:31, Kjell Rilbe wrote:
>>> So far, these are the suggestions I've seen
>> Hey, how about my suggestion leave everything as is and perform
>> backup-restore cycle on
>> demand?..
>>
>>
02.01.2012 1:38, Steve Friedl wrote:
> On Sun, Jan 01, 2012 at 08:14:56PM -0400, W O wrote:
>> > Right, but it take more time for type them and the probability of mistakes
>> > grows.
> Sure, but if long passwords are allowed, people have a choice as to their
> own tradeoff of security -vs- conve
17 matches
Mail list logo
