Re: Logical Replication WIP - Mailing list pgsql-hackers

 

I don't think so. The checkpointer, walwriter, autovacuum, etc predate bgworkers. I strongly suspect that if they were to be implemented now they'd use bgworkers.

Now, perhaps we want a new bgworker "kind" for system workers or some other minor tweaks. But basically I think bgworkers are exactly what we should be using here.

 

Well, they *are* worker processes... but I take your point, that that setting has been "number of bgworkers the user can run" and it might not be expected that logical replication would use the same space.

max_worker_progresses isn't just a limit, it controls how many shmem slots we allocate.

I guess we could have a separate max_logical_workers or something, but I'm inclined to think that adds complexity without really making things any nicer. We'd just add them together to decide how many shmem slots to allocate and we'd have to keep track of how many slots were used by which types of backend. Or create a near-duplicate of the bgworker facility for logical rep.

Sure, you can go deeper down the rabbit hole here and say that we need to add bgworker "categories" with reserved pools of worker slots for each category. But do we really need that?

max_connections includes everything, both system and user backends. It's not like we don't do this elsewhere. It's at worst a mild wart.

The only argument I can see for not using bgworkers is for the supervisor worker. It's a singleton that launches the per-database workers, and arguably is a job that the postmaster could do better. The current design there stems from its origins as an extension. Maybe worker management could be simplified a bit as a result. I'd really rather not invent yet another new and mostly duplicate category of custom workers to achieve that though.