gc: do not use WAL watcher API for deactivating stale consumers
The WAL thread may delete old WAL files if it gets ENOSPC error. Currently, we use WAL watcher API to notify the TX thread about it so that it can shoot off stale replicas. This looks ugly, because WAL watcher API was initially designed to propagate WAL changes to relay threads and the new event WAL_EVENT_GC, which was introduced for notifying about ENOSPC-driven garbage collection, isn't used anywhere else. Besides, there's already a pipe from WAL to TX - we could reuse it instead of opening another one. If we followed down that path, then in order to trigger a checkpoint from the WAL thread (see #1082), we would have to introduce yet another esoteric WAL watcher event, making the whole design look even uglier. That said, let's rewrite the garbage collection notification procedure using a plane callback instead of abusing WAL watcher API.
Loading
Please register or sign in to comment