Hi, On Fri, Feb 14, 2025 at 12:17:48AM -0800, Masahiko Sawada wrote: > On Tue, Feb 11, 2025 at 11:44 PM Bertrand Drouvot > <bertranddrouvot...@gmail.com> wrote:
> Looking at the latest custodian worker patch, the basic architecture > is to have a single custodian worker and processes can ask it for some > work such as removing logical decoding related files. The online > wal_level change will be the one of the tasks that processes (eps. > checkpointer) can ask for it. On the other hand, one point that I > think might not fit this wal_level work well is that while the > custodian worker is a long-lived worker process, That was the case initialy but it looks like it would not have been the case at the end. See, Tom's comment in [1]: " I wonder if a single long-lived custodian task is the right model at all. At least for RemovePgTempFiles, it'd make more sense to write it as a background worker that spawns, does its work, and then exits, independently of anything else " > it's sufficient for > the online wal_level change work to have a bgworker that does its work > and then exits. Fully agree and I did not think about changing this behavior. > IOW, from the perspective of this work, I prefer the > idea of having one short-lived worker for one task over having one > long-lived worker for multiple tasks. Yeah, or one short-lived worker for multiple tasks could work too. It just starts when it has something to do and then exit. > Reading that thread, while we > need to resolve the XID wraparound issue for the work of removing > logical decoding related files, the work of removing temporary files > seems to fit a short-lived worker style. So I thought as one of the > directions, it might be worth considering to have an infrastructure > where we can launch a bgworker just for one task, and we implement the > online wal_level change and temporary files removal on top of it. Yeap, that was exactly my point when I mentioned the custodian thread (taking into account Tom's comment quoted above). Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
