On 19 September 2017 at 20:33, Amit Kapila <amit.kapil...@gmail.com> wrote:
> Yeah, but you could have used the way we do for parallel query where > we setup dsm and share all such information. You can check the logic > of execparallel.c and parallel.c to see how we do all such stuff for > parallel query. Parallel query has a very clearly scoped lifetime, which seems to help. The parallel workers are started by a leader, whose lifetime entirely encompasses that of the workers. They're strictly children of the leader process. In logical replication, the logical replication manager doesn't start the walsenders, they're started by the postmaster in response to inbound connections. But the logical replication launcher does start the managers, and the managers start the apply workers. (IIRC). If we don't mind the whole thing dying and restarting if the launcher dies, or workers for a db dying if a database manager dies, then using dsm segments and detach notifications does seem viable. IIRC when we did something similar in pglogical we ran into problems with (a) inability to handle an ERROR in a bgworker without exiting and being restarted by the postmaster; and (b) the postmaster remembering bgworker registrations across crash restart with no way to tell it not to. Maybe Petr remembers the details? -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
