Patrick Bédat

> Is the 91 bytes the compressed or uncompressed size of the WAL files? The compressed size > It can also be useful to run hexdump -C on the uncompressed...

Here is a diff of two subsequent wal frames: ```bash diff

@Bluebugs under what condition did it happen to you? After it happened again after a service restart, I believe there might be a correlation. I'm not 100% sure if docker...

@Bluebugs when litestream enters this faulty state (whatever the reason) the flooding seems to start only after the first write has been done to the db. So it might enter...

@bluebrown I think your issue is related to a problem with AUTOINCREMENT tables. Already opened a PR for this @stephenafamo : https://github.com/volatiletech/sqlboiler/pull/1130 @bluebrown As a workaround, try to remove "completeted"...

I fixed this on a fork of the mailgun/raymond repo: https://github.com/mailgun/raymond/compare/master...pbedat:raymond:master

@hifi I guess you are right about lz4.  [pprof.litestream.alloc_objects.alloc_space.inuse_objects.inuse_space.001.pb.gz](https://github.com/benbjohnson/litestream/files/14077467/pprof.litestream.alloc_objects.alloc_space.inuse_objects.inuse_space.001.pb.gz) PS: I took the snapshot from replication setup with only 4 DBs. Hence the smaller size.

Never mind. It's not a problem, since I'm getting alerts, when replicas go unhealthy and can respond before memory runs out. Thank's for clearifying it!

@hifi I was able to track down the situation, that caused the flooding. **TL;DR two Litestream instances replicating the same DB file in parallel** First, some context: We are using...

@hifi the "long running read transaction" is actually the mechanism, that allows Litestream do its job :) https://litestream.io/how-it-works/#the-shadow-wal That might also explain, why to parallel litestream instances cause the flodding...