aboutsummaryrefslogtreecommitdiff
path: root/src/database_sqlite.cc
diff options
context:
space:
mode:
authorfusion32 <marcopuzziello@gmail.com>2025-10-16 01:35:10 -0300
committerfusion32 <marcopuzziello@gmail.com>2025-10-16 01:46:10 -0300
commit95022ca95b1d2792bae447d90694dcc0d67b9de2 (patch)
tree3a23505d31c48188f537a6da95239215a6487297 /src/database_sqlite.cc
parentb49d7de51cf14632a5768f292b870e647cf39bf5 (diff)
downloadquerymanager-95022ca95b1d2792bae447d90694dcc0d67b9de2.tar.gz
querymanager-95022ca95b1d2792bae447d90694dcc0d67b9de2.zip
lower monotonic uptime resolution from MILLISECONDS to SECONDS
The monotonic uptime was used exclusively with caches and having a resolution of SECONDS allows it to be stored as an int without risk of wrapping (~68 years). Using MILLISECONDS meant that it would wrap after ~25 days which is totally possible and EXPECTED. Just as an example, the small test server I ran for about 1 month had ZERO downtime on the QueryManager except for when I manually restarted it. It was probably very close to wrapping when I took it down.
Diffstat (limited to 'src/database_sqlite.cc')
-rw-r--r--src/database_sqlite.cc4
1 files changed, 2 insertions, 2 deletions
diff --git a/src/database_sqlite.cc b/src/database_sqlite.cc
index b50c6df..bcc4914 100644
--- a/src/database_sqlite.cc
+++ b/src/database_sqlite.cc
@@ -94,7 +94,7 @@ static sqlite3_stmt *PrepareQuery(TDatabase *Database, const char *Text){
ASSERT(EntryText != NULL);
if(StringEq(EntryText, Text)){
Stmt = Entry->Stmt;
- Entry->LastUsed = GetMonotonicUptimeMS();
+ Entry->LastUsed = GetMonotonicUptime();
break;
}
}
@@ -113,7 +113,7 @@ static sqlite3_stmt *PrepareQuery(TDatabase *Database, const char *Text){
}
Entry->Stmt = Stmt;
- Entry->LastUsed = GetMonotonicUptimeMS();
+ Entry->LastUsed = GetMonotonicUptime();
Entry->Hash = Hash;
}else{
if(sqlite3_stmt_busy(Stmt) != 0){