On 09/08/16 10:13, Craig Ringer wrote:
On 9 August 2016 at 15:59, Masahiko Sawada <sawada.m...@gmail.com
<mailto:sawada.m...@gmail.com>> wrote:
The logical replication launcher process and the apply process are
implemented as a bgworker. Isn't better to have them as an auxiliary
process like checkpointer, wal writer?
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.
Agreed.
IMO the number of logical replication connections should not be
limited by max_worker_processes.
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.
Again agree, I think we should ultimately go towards what PeterE
suggested in
https://www.postgresql.org/message-id/a2fffd92-6e59-a4eb-dd85-c5865ebca...@2ndquadrant.com
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.
It is simplified compared to pglogical (there is only 2 worker types not
3). I don't think it's job of postmaster to scan catalogs however so it
can't really start workers for logical replication. I actually modeled
it more after autovacuum (using bgworkers though) than the original
extension.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
