|
Title: No-recompilation fix for the "Lock table is out of available lock entries" Post by: 2112 on March 12, 2013, 10:08:16 AM Just create the file named "DB_CONFIG" in the ".bitcoin" or "AppData/Roaming/Bitcoin" directory that contains the following:
Code: set_lg_dir database Please don't omit the "set_lg_dir database" line. Without it you may corrupt the "_db.00?" and/or "log.*" files if you are unlucky and run the Berkeley DB utilities like "db_stat". With this line you will at worst get the error message from those utilities. Good luck. Edit: Oh, I forgot about the most obvious or non-obvious: restart the bitcoind/bitcoin-qt. Title: Re: No-recompilation fix for the "Lock table is out of available lock entries" Post by: bitcoinBull on March 12, 2013, 05:44:47 PM This why any settings should always be set explicitly, even if they have defaults. It makes it harder to forget about them.
Title: Re: No-recompilation fix for the "Lock table is out of available lock entries" Post by: paraipan on March 12, 2013, 06:52:50 PM ... Please don't! You will only make the things worse. Changing this setting is useless if the majority doesn't apply it, and you can even end up on a blockchain fork by yourself. Title: Re: No-recompilation fix for the "Lock table is out of available lock entries" Post by: marcus_of_augustus on March 12, 2013, 06:57:04 PM ... Please don't! You will only make the things worse. Changing this setting is useless if the majority doesn't apply it, and you can even end up on a blockchain fork by yourself. Don't you think it is about time the "majority" decided what is best for the blockchain? The reference implementation allows it. Upgrading via a hard fork is not the answer. The block limit needs to be decided by a consensus of the mining power and it is high time this issue was sorted out ... unless SatoshiDICE wants to do the right thing. Title: Re: No-recompilation fix for the "Lock table is out of available lock entries" Post by: paraipan on March 12, 2013, 06:59:36 PM ... Please don't! You will only make the things worse. Changing this setting is useless if the majority doesn't apply it, and you can even end up on a blockchain fork by yourself. Don't you think it is about time the "majority" decided what is best for the blockchain? The reference implementation allows it. Upgrading via a hard fork is not the answer. The block limit needs to be decided by a consensus of the mining power and it is high time this issue was sorted out ... unless SatoshiDICE wants to do the right thing. Meh, I'm always with the majority like everyone else around these parts. Only thing is modifying such setting would get individuals prone to attack because miner majority will be still on 0.7 blockchain and software limitations. Only informing here, don't take it with me. Title: Re: No-recompilation fix for the "Lock table is out of available lock entries" Post by: gmaxwell on March 12, 2013, 07:46:14 PM Don't you think it is about time the "majority" decided what is best for the blockchain? You're confusing two things. Pool operators and solo miners are only a _tiny_ subset of the users of the system, ones whos motivations are not always well aligned with everyone elses and are often only aligned by all the things they cannot control. For example, if it were really just up to miners— 50 BTC _forever_. But fortunately no one elses nodes would accept their inflationary blocks. Amusingly, turning things over to a majority of core developers would make it depend on more people than a majority of hashpower (which is very close to being decided by a single person right now); not that either is remotely acceptable.The reference implementation allows it. Upgrading via a hard fork is not the answer. The block limit needs to be decided by a consensus of the mining power and it is high time this issue was sorted out ... unless SatoshiDICE wants to do the right thing. Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users. Title: Re: No-recompilation fix for the "Lock table is out of available lock entries" Post by: marcus_of_augustus on March 12, 2013, 08:23:19 PM Here's the Berkeley DB tutorial for anyone who might want to do some reading on sizing your database correctly and lock limits.
http://www.stanford.edu/class/cs276a/projects/docs/berkeleydb/ref/lock/max.html (http://www.stanford.edu/class/cs276a/projects/docs/berkeleydb/ref/lock/max.html) Quote The maximum number of locks required by an application cannot be easily estimated. It is possible to calculate a maximum number of locks by multiplying the maximum number of lockers, times the maximum number of lock objects, times two (two for the two possible lock modes for each object, read and write). However, this is a pessimal value, and real applications are unlikely to actually need that many locks. Reviewing the Lock subsystem statistics is the best way to determine this value. Title: Re: No-recompilation fix for the "Lock table is out of available lock entries" Post by: paraipan on March 12, 2013, 08:43:45 PM Here's the Berkeley DB tutorial for anyone who might want to do some reading on sizing your database correctly and lock limits. http://www.stanford.edu/class/cs276a/projects/docs/berkeleydb/ref/lock/max.html (http://www.stanford.edu/class/cs276a/projects/docs/berkeleydb/ref/lock/max.html) Quote The maximum number of locks required by an application cannot be easily estimated. It is possible to calculate a maximum number of locks by multiplying the maximum number of lockers, times the maximum number of lock objects, times two (two for the two possible lock modes for each object, read and write). However, this is a pessimal value, and real applications are unlikely to actually need that many locks. Reviewing the Lock subsystem statistics is the best way to determine this value. Lol ^ they said the same thing about IPv4 when it was invented, who would need more than 4,294,967,296 IP addresses? Time for "Bitcoin-IPv6" databases, which 0.8 already uses. Title: Re: No-recompilation fix for the "Lock table is out of available lock entries" Post by: bitcoinBull on March 12, 2013, 09:14:38 PM Lol ^ they said the same thing about IPv4 when it was invented, who would need more than 4,294,967,296 IP addresses? Time for "Bitcoin-IPv6" databases, which 0.8 already uses. In 0.8 BerkeleyDB was replaced with LevelDB. Title: Re: No-recompilation fix for the "Lock table is out of available lock entries" Post by: paraipan on March 12, 2013, 10:43:30 PM Lol ^ they said the same thing about IPv4 when it was invented, who would need more than 4,294,967,296 IP addresses? Time for "Bitcoin-IPv6" databases, which 0.8 already uses. In 0.8 BerkeleyDB was replaced with LevelDB. ^ exactly my point Title: Re: No-recompilation fix for the "Lock table is out of available lock entries" Post by: marcus_of_augustus on March 13, 2013, 02:30:58 AM Lol ^ they said the same thing about IPv4 when it was invented, who would need more than 4,294,967,296 IP addresses? Time for "Bitcoin-IPv6" databases, which 0.8 already uses. In 0.8 BerkeleyDB was replaced with LevelDB. ^ exactly my point but levelDB implementation didn't faithfully reproduce BDB behaviour, which is what it was minimally asked to do ... and that is what caused the fork. 0.7 and BDB is still king ... for now, for better or worse, for richer or poorer, etc ... bitcoiners are wedded to it. |