Bitcoin Forum
July 26, 2021, 06:03:57 PM *
News: Latest Bitcoin Core release: 0.21.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: No-recompilation fix for the "Lock table is out of available lock entries"  (Read 7289 times)
2112
Legendary
*
Offline Offline

Activity: 2128
Merit: 1038



View Profile
March 12, 2013, 10:08:16 AM
Last edit: March 12, 2013, 04:07:36 PM by 2112
 #1

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.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
1627322637
Hero Member
*
Offline Offline

Posts: 1627322637

View Profile Personal Message (Offline)

Ignore
1627322637
Reply with quote  #2

1627322637
Report to moderator
1627322637
Hero Member
*
Offline Offline

Posts: 1627322637

View Profile Personal Message (Offline)

Ignore
1627322637
Reply with quote  #2

1627322637
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1627322637
Hero Member
*
Offline Offline

Posts: 1627322637

View Profile Personal Message (Offline)

Ignore
1627322637
Reply with quote  #2

1627322637
Report to moderator
1627322637
Hero Member
*
Offline Offline

Posts: 1627322637

View Profile Personal Message (Offline)

Ignore
1627322637
Reply with quote  #2

1627322637
Report to moderator
1627322637
Hero Member
*
Offline Offline

Posts: 1627322637

View Profile Personal Message (Offline)

Ignore
1627322637
Reply with quote  #2

1627322637
Report to moderator
bitcoinBull
Legendary
*
Offline Offline

Activity: 826
Merit: 1001


rippleFanatic


View Profile
March 12, 2013, 05:44:47 PM
 #2

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

College of Bucking Bulls Knowledge
paraipan
Legendary
*
Offline Offline

Activity: 924
Merit: 1003


Firstbits: 1pirata


View Profile WWW
March 12, 2013, 06:52:50 PM
 #3

...

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.

BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 3612
Merit: 1848



View Profile
March 12, 2013, 06:57:04 PM
 #4

...

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
Legendary
*
Offline Offline

Activity: 924
Merit: 1003


Firstbits: 1pirata


View Profile WWW
March 12, 2013, 06:59:36 PM
 #5

...

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.

BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
gmaxwell
Moderator
Legendary
*
expert
Online Online

Activity: 3486
Merit: 5532



View Profile
March 12, 2013, 07:46:14 PM
 #6

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
Legendary
*
Offline Offline

Activity: 3612
Merit: 1848



View Profile
March 12, 2013, 08:23:19 PM
 #7

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

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.

paraipan
Legendary
*
Offline Offline

Activity: 924
Merit: 1003


Firstbits: 1pirata


View Profile WWW
March 12, 2013, 08:43:45 PM
 #8

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

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.

BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
bitcoinBull
Legendary
*
Offline Offline

Activity: 826
Merit: 1001


rippleFanatic


View Profile
March 12, 2013, 09:14:38 PM
 #9

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.

College of Bucking Bulls Knowledge
paraipan
Legendary
*
Offline Offline

Activity: 924
Merit: 1003


Firstbits: 1pirata


View Profile WWW
March 12, 2013, 10:43:30 PM
 #10

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

BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 3612
Merit: 1848



View Profile
March 13, 2013, 02:30:58 AM
 #11

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.

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!