On Fri, Aug 04, 2017 at 11:53:05AM -0500, Nico Williams wrote: > WAL mode still ends up having no read concurrency when it's time to > checkpoint the WAL. The same would happen with this concept. I don't > think this works well.
Speaking of which... and I know I've mentioned this before and I risk being a broken record... Imagine a mode where there is only a WAL, and to checkpoint is to write a new WAL with only live contents and... rename(2) into place. Such a mode would a) be a 100% Copy-on-Write (CoW) mode, whereas currently WAL is only CoW until a checkpoint operation comes along, b) have better read concurrency. A special marker could be used to denote "this WAL is closed and replaced with a checkpointed one", that way readers only have to stat/re-open when they see this. It probably wouldn't take much to write such a thing. One nice thing about this is that block-level replication would be easy and fast because all writes would be append-writes: just send missing blocks until the file ID (st_dev, st_ino, and inode gen number) changes, then send the whole new file. (Not that block-level replication is an end-all-be-all. But that for some use cases it's very nice. Logical replication is better for other use-cases.) Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
