From Newsgroup: news.software.nntp

I have two servers running INN 2.8.0 with different snapshot versions. With my original/old server running an older snapshot when an article is accepted it
is immediately available in the overview database. On the new server there is
a ~10 second delay before accepted articles appear in the overview database.

Old server: INN 2.8.0 (20250329 snapshot)
New server: INN 2.8.0 (20260703 snapshot)

I know there has been recent work on ovsqlite, and I'm not sure if code
changes could be to blame, or something else but I'm out of ideas.

Thought this could be due to a difference in transtimelimit, but the servers are configured the same in that respect. On the new server it feels like it's waiting ~10 seconds to commit the transaction, whereas on the older server it is near instant.

20250329 snapshot ovsqlite.conf
compress: true
pagesize: 65536
cachesize: 8000
transrowlimit: 10000
transtimelimit: 10.0

20260703 snapshot ovsqlite.conf
walmode: true
pagesize: 65536
cachesize: 65536
transrowlimit: 10000
transtimelimit: 10.0
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.software.nntp

Hi Jesse,

I have two servers running INN 2.8.0 with different snapshot versions. With my
original/old server running an older snapshot when an article is accepted it is immediately available in the overview database. On the new server there is a ~10 second delay before accepted articles appear in the overview database.

Old server: INN 2.8.0 (20250329 snapshot)
New server: INN 2.8.0 (20260703 snapshot)

I know there has been recent work on ovsqlite, and I'm not sure if code changes could be to blame, or something else but I'm out of ideas.

I think the difference was introduced with WAL mode:

"""
walmode (ovsqlite.conf)

If this parameter is true, ovsqlite will use SQLite's WAL (Write-Ahead Logging) journal mode instead of the default PERSIST mode. WAL mode
allows concurrent readers and writers without blocking, which
significantly improves read performance when multiple nnrpd processes
access the overview database simultaneously. It also sets "synchronous"
to NORMAL, which is safe with WAL and reduces unnecessary fsync overhead.
"""

According to SQLite documentation (https://sqlite.org/pragma.html), the "synchronous" flag is FULL by default, and indeed keeps synchronizing
all content to disk. With WAL, the NORMAL setting seems to be
encouraged to save that synchronization.

Thought this could be due to a difference in transtimelimit, but the servers are configured the same in that respect. On the new server it feels like it's waiting ~10 seconds to commit the transaction, whereas on the older server it is near instant.

I bet the NORMAL setting then uses that max time for a transaction (transtimelimit). Kevin or Bo, our SQL experts, will probably confirm.

Is that behaviour troublesome for you or a special use case?
Maybe we would then need for instance a "fullsynchronous" (true/false)
setting in ovsqlite.conf to configure that if needed? The previous
behaviour of FULL corresponds to true, whereas WAL mode makes it false.

Or you can decrease the transtimelimit parameter.
--
Julien |eLIE

-2-aJe suis adroit de la main gauche et je suis gauche de la main
droite.-a-+ (Raymond Devos)

--- Synchronet 3.22a-Linux NewsLink 1.2