Den 2012-01-01 23:47 skrev Lester Caine såhär:
> Dimitry Sibiryakov wrote:
>> 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?..
>>
>> Pros:
>> - No
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- convenience. If only short passwords are
allowed, Fireb
Right, but it take more time for type them and the probability of mistakes
grows.
Greetings.
Walter.
On Wed, Dec 21, 2011 at 11:12 PM, Doug Chamberlin wrote:
> Why limit it to so little? Make the limit 1KB or 2KB to encourage pass
> phrases instead of passwords.
>
> Full sentences that are m
Dimitry Sibiryakov wrote:
> 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?..
>
> Pros:
> - No overhead.
> - No additional disk space.
> - No code change
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?..
>
> Pros:
> - No overhead.
> - No additional disk s
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?..
Pros:
- No overhead.
- No additional disk space.
- No code change.
Cons:
- DBA with brain is required.
--
So far, these are the suggestions I've seen (I'm adding my own
suggestion at the bottom):
1. Implement 64 bit id:s and use them everywhere always.
Pros:
- Straightforward once all code has been changed to use 64 bit id:s.
- No overhead for various special flags and stuff.
Cons:
- Will increase di
>Nobody needs more than 4 billions active transactions concurrently.
But that's not what you'll get, because you can complete transactions
and get a hol, as it were. Can a process grab a transaction id and hold
onto it 'for ever' without messing up the system in other ways that
preventing the
01.01.2012 18:22, Adriano dos Santos Fernandes wrote:
> Let something like sweep consolidate old transactions in only one,
> concurrently with user operations.
Sweep is mostly read-only operation which is known to cause intolerable
slowdown.
Everybody turn it off because of that. You are sugg
On 01-01-2012 15:11, Jesús García wrote:
>
> I think the question is if it is neccesary and good for Firebird, and if the
> pros of having transactions id of 64bits are better that the cons of not
> having it. From my POV using 32 bits id is an important restriction in the
> engine, and i would
>
> Disk speed was always the issue, it doesn't increase that fast as
> CPU/memory speed. So the on-disk size always matters quite a lot.
>
>
> Dmitry
I think the question is if it is neccesary and good for Firebird, and if the
pros of having transactions id of 64bits are better that the cons
>
> CPU speed also has stopped growing.
>
You are right, speed has stopped but performance has increased.
Jesus
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT r
01.01.2012 14:06, Dmitry Yemanov wrote:
> Disk speed was always the issue, it doesn't increase that fast as
> CPU/memory speed. So the on-disk size always matters quite a lot.
CPU speed also has stopped growing.
--
SY, SD.
--
01.01.2012 16:48, Jesus Garcia wrote:
>
> Is not better use 64 bits integer?. In the near future computers speed, hdd
> speeds, etc. will increase, and transaction id of 64 bits overhead will
> affect less and less to performance.
Disk speed was always the issue, it doesn't increase that fast as
>
> We have 7 or 8 bits (out of 16) currently available.
>
>
> Dmitry
Is not better use 64 bits integer?. In the near future computers speed, hdd
speeds, etc. will increase, and transaction id of 64 bits overhead will affect
less and less to performance.
Jesus
---
01.01.2012 14:34, Kjell Rilbe wrote:
> Are there unused flag bits available in the current record format, that
> could be used for this purpose? Or how are such flag bits encoded?
We have 7 or 8 bits (out of 16) currently available.
Dmitry
--
How much would it help if I bolted IBO on top of the new API?
In this way, people who have applications written in IBO could be tested.
Jason
www.ibobjects.com
-Original Message-
From: Adriano dos Santos Fernandes [mailto:adrian...@gmail.com]
Sent: 16 December 2011 06:30 AM
To: For discu
Why limit it to so little? Make the limit 1KB or 2KB to encourage pass
phrases instead of passwords.
Full sentences that are meaningful to the person are WAY better
protection than complex passwords.
On 12/21/11 4:19 PM, W O wrote:
> Just 8 letters for a password seems to me very short.
>
> It is
Den 2011-12-31 15:08 skrev Dmitry Yemanov såhär:
> 31.12.2011 17:57, Alexander Peshkov wrote:
>
>> This will make each version of the record (not the record- but EACH
>> version of it) 4 bytes longer.
> Not strictly necessary. We could use a variable-length encoding for txn
> ids longer than 32 bit
19 matches
Mail list logo
