> I see that there this problem was analized "completly"
More-or-less
> Is this really plan to fix this in FB3.0
None, AFAIK
> Vlad Korshun say that only transaction id will be unsigned int in FB3.0 - is
> this true
> or is in plan to fix this with two record header versions or other s
"Larry Baddock" napisał(a):
>discussion about http://tracker.firebirdsql.org/browse/CORE-2348
>I have solution for this problem reuse transaction id feature.
I guess you are referring to something like this solution, discussed in 2005:
http://firebird.1100200.n4.nabble.com/High-Volume-Solution-Need
>discussion about http://tracker.firebirdsql.org/browse/CORE-2348
>I have solution for this problem reuse transaction id feature.
I guess you are referring to something like this solution, discussed in 2005:
http://firebird.1100200.n4.nabble.com/High-Volume-Solution-Needed-td1107716.html
Kind
27.04.2011 21:01, Mercea Paul wrote:
> Is Firebird server cluster ready? I mean for this scenario with multiple
> server without replication but cluster !
It sounds like you refuse to call shared-nothing architecture "a cluster"...
--
SY, SD.
--
On 2011-04-27 4:39 PM, Dimitry Sibiryakov wrote:
> 27.04.2011 15:33, Kjell Rilbe wrote:
>> Step 2 may be a big problem for 24/7 servers
> 24/7 systems should not be based on a single server, so, while one node
> is performing
> classic backup-restore or suggested procedure, all users can be se
27.04.2011 15:33, Kjell Rilbe wrote:
> Step 2 may be a big problem for 24/7 servers
24/7 systems should not be based on a single server, so, while one node is
performing
classic backup-restore or suggested procedure, all users can be served by other
node(s).
--
SY, SD.
Den 2011-04-27 14:43 skrev liviusliv...@poczta.onet.pl såhär:
> Hi
>
> discussion about http://tracker.firebirdsql.org/browse/CORE-2348
>
> I have solution for this problem reuse transaction id feature.
>
> When oldest active transaction id reach e.g. 1 500 000 001 value (shuld
> be big as possible
Hi
discussion about http://tracker.firebirdsql.org/browse/CORE-2348
I have solution for this problem reuse transaction id feature.
When oldest active transaction id reach e.g. 1 500 000 001 value (shuld be big
as possible but have also big difference to max integer value).
then:
1. set "reset f