| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Petr Jelinek <petr(at)2ndquadrant(dot)com> |
| Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Logical Replication WIP |
| Date: | 2016-08-09 20:32:44 |
| Message-ID: | 20160809203244.GA583049@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Petr Jelinek wrote:
> On 09/08/16 10:13, Craig Ringer wrote:
> >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.
Yeah, it's a very bad idea to put postmaster on this task. We should
definitely stay away from that.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2016-08-09 20:48:58 | Re: per-statement-level INSTEAD OF triggers |
| Previous Message | Alvaro Herrera | 2016-08-09 20:31:02 | Re: Logical Replication WIP |