Re: POC: enable logical decoding when wal_level = 'replica' without a server restart
От | Bertrand Drouvot |
---|---|
Тема | Re: POC: enable logical decoding when wal_level = 'replica' without a server restart |
Дата | |
Msg-id | Z68ciLRO2lBAg7LM@ip-10-97-1-34.eu-west-3.compute.internal обсуждение исходный текст |
Ответ на | Re: POC: enable logical decoding when wal_level = 'replica' without a server restart (Masahiko Sawada <sawada.mshk@gmail.com>) |
Список | pgsql-hackers |
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.pg@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
В списке pgsql-hackers по дате отправления: