Re: src/test/subscription/t/002_types.pl hanging on particular environment

On 19 September 2017 at 20:33, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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