vfs: Fix the short read check in vfsWalRead

[cole-miller]

Problem

When trying to read a page from the WAL, we bail early with an error if there are no committed pages in struct vfsWal. But sometimes a transaction will want to read its own WAL frames that haven't been committed yet, and this check will prevent that if the transaction starts out with an empty WAL (because it's running right after a checkpoint, for example).

Solution

Remove the separate check for w->n_frame == 0 and just see whether vfsWalFrameLookup returns NULL, indicating that there's no frame at the given index. vfsWalFrameLookup can retrieve frames from either w->frames or w->tx.

Closes #432

Signed-off-by: Cole Miller cole.miller@canonical.com

[codecov]

Codecov Report

Merging #445 (f9802d0) into master (50ee9af) will increase coverage by 0.11%.
The diff coverage is 33.33%.

@@            Coverage Diff             @@
##           master     #445      +/-   ##
==========================================
+ Coverage   74.21%   74.33%   +0.11%     
==========================================
  Files          32       32              
  Lines        5380     5381       +1     
  Branches     1682     1682              
==========================================
+ Hits         3993     4000       +7     
+ Misses        823      821       -2     
+ Partials      564      560       -4     

Impacted Files	Coverage Δ
src/vfs.c	83.97% <33.33%> (+0.20%)	⬆️
src/transport.c	69.93% <0.00%> (+0.65%)	⬆️
src/lib/transport.c	91.42% <0.00%> (+1.90%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[cole-miller]

One concern I had is that if a transaction is pending on one connection, other connections should definitely not be able to read uncommitted WAL data from that transaction; vfsWalRead itself doesn't have any checks around this, before or after this change. I think it should be taken care of by each connection having to hold the appropriate locks before trying to read from the WAL -- is that right?

[freeekanayaka]

One concern I had is that if a transaction is pending on one connection, other connections should definitely not be able to read uncommitted WAL data from that transaction; vfsWalRead itself doesn't have any checks around this, before or after this change. I think it should be taken care of by each connection having to hold the appropriate locks before trying to read from the WAL -- is that right?

That's right, it's not a VFS concern. SQLite takes care of it by taking note of the highest committed WAL frame number at the time the transaction started, and never reading past it.