Patch to raise SQLITE_MAX_ATTACHED above 125
(1) By anonymous on 2020-03-25 15:55:11 [source]
Hi,
I know this might be a terrible idea, but just in case someone really needs this, the below patch raises the possible SQLITE_MAX_ATTACHED limit to 1024. Make sure to raise your ulimit -Sn too, otherwise you'll run out of file descriptors on Linux (wal dbs take 3 fds each).
diff -ur sqlite-src-3310100/src/main.c sqlite-src-3310100-attlimit/src/main.c
--- sqlite-src-3310100/src/main.c 2020-01-27 21:25:04.000000000 +0100
+++ sqlite-src-3310100-attlimit/src/main.c 2020-03-25 15:19:09.350932673 +0100
@@ -2664,8 +2664,8 @@
#if SQLITE_MAX_FUNCTION_ARG<0 || SQLITE_MAX_FUNCTION_ARG>127
# error SQLITE_MAX_FUNCTION_ARG must be between 0 and 127
#endif
-#if SQLITE_MAX_ATTACHED<0 || SQLITE_MAX_ATTACHED>125
-# error SQLITE_MAX_ATTACHED must be between 0 and 125
+#if SQLITE_MAX_ATTACHED<0 || SQLITE_MAX_ATTACHED>1024
+# error SQLITE_MAX_ATTACHED must be between 0 and 1024
#endif
#if SQLITE_MAX_LIKE_PATTERN_LENGTH<1
# error SQLITE_MAX_LIKE_PATTERN_LENGTH must be at least 1
diff -ur sqlite-src-3310100/src/memdb.c sqlite-src-3310100-attlimit/src/memdb.c
--- sqlite-src-3310100/src/memdb.c 2020-01-27 21:25:04.000000000 +0100
+++ sqlite-src-3310100-attlimit/src/memdb.c 2020-03-24 12:11:15.086050235 +0100
@@ -576,7 +576,7 @@
rc = sqlite3_prepare_v2(db, zSql, -1, &pStmt, 0);
sqlite3_free(zSql);
if( rc ) goto end_deserialize;
- db->init.iDb = (u8)iDb;
+ db->init.iDb = iDb;
db->init.reopenMemdb = 1;
rc = sqlite3_step(pStmt);
db->init.reopenMemdb = 0;
diff -ur sqlite-src-3310100/src/prepare.c sqlite-src-3310100-attlimit/src/prepare.c
--- sqlite-src-3310100/src/prepare.c 2020-01-27 21:25:04.000000000 +0100
+++ sqlite-src-3310100-attlimit/src/prepare.c 2020-03-24 12:10:59.901120744 +0100
@@ -109,7 +109,7 @@
** structures that describe the table, index, or view.
*/
int rc;
- u8 saved_iDb = db->init.iDb;
+ int saved_iDb = db->init.iDb;
sqlite3_stmt *pStmt;
TESTONLY(int rcp); /* Return code from sqlite3_prepare() */
diff -ur sqlite-src-3310100/src/sqliteInt.h sqlite-src-3310100-attlimit/src/sqliteInt.h
--- sqlite-src-3310100/src/sqliteInt.h 2020-01-27 21:25:04.000000000 +0100
+++ sqlite-src-3310100-attlimit/src/sqliteInt.h 2020-03-24 12:10:25.406902633 +0100
@@ -1457,7 +1457,7 @@
int nMaxSorterMmap; /* Maximum size of regions mapped by sorter */
struct sqlite3InitInfo { /* Information used during initialization */
int newTnum; /* Rootpage of table being initialized */
- u8 iDb; /* Which db file is being initialized */
+ int iDb; /* Which db file is being initialized */
u8 busy; /* TRUE if currently initializing */
unsigned orphanTrigger : 1; /* Last statement is orphaned TEMP trigger */
unsigned imposterTable : 1; /* Building an imposter table */
Pawel Foremski pjf@fsi.io, www.farsightsecurity.com
(2) By Raymi (Raymi_C) on 2022-05-29 11:25:42 in reply to 1 [link] [source]
Hello,
Being somehow frustrated for a long time because of the SQLITE_MAX_ATTACHED limitation, I would like to understand why SQLite has always been using a 8-bits integer to handle this max connections. I'm convinced there must be good reasons for that.
The patch you suggest sounds interesting but I'm so much afraid of the hidden impacts this might have.
When you mention one's should raise the "ulimit -Sn", in your example do you mean it should then be 3 * 1024 because of WAL?
Thx