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.


    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:

Reply via email to