No-recompilation fix for the "Lock table is out of available lock entries"

[2112]

Just create the file named "DB_CONFIG" in the ".bitcoin" or "AppData/Roaming/Bitcoin" directory that contains the following:

Code:

set_lg_dir database
set_lk_max_locks 40000

The default was 10000. You can monitor the lock usage using "db_stat -e". I've tested it on an old laptop with 0.3.24 and 0.5.0. Obviously it will work with alt-coins based on the Bitcoin & BDB code. The same file should go into the respective "testnet" subdirectories.

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.

[1715277538]

1715277538

[1715277538]

1715277538

[1715277538]

1715277538

[1715277538]

1715277538

[bitcoinBull]

This why any settings should always be set explicitly, even if they have defaults. It makes it harder to forget about them.

[paraipan]

...

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.

[marcus_of_augustus]

...

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.

[paraipan]

...

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.

[gmaxwell]

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.

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.

Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users.

[marcus_of_augustus]

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

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.

[paraipan]

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

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.

[bitcoinBull]

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.

[paraipan]

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

[marcus_of_augustus]

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.